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FOREWORD 

Among  the  responsibilities  assigned  to  the  Office  of  the  Manager,  National 
Communications  System,  is  the  management  of  the  Federal  Telecommunication 
Standards  Program.  Under  this  program,  the  NCS,  with  the  assistance  of  the 
Federal  Telecommunication  Standards  Committee  identified,  develops,  and 
coordinates  proposed  Federal  Standards  which  either  contribute  to  the 
interoperability  of  functionally  similar  Federal  telecommunication  systems  or 
to  the  achievement  of  a  compatible  and  efficient  interface  between  computer  and 
telecommunication  systems.  In  developing  and  coordinating  these  standards,  a 
considerable  amount  of  effort  is  expended  in  initiating  and  pursuing  joint 
standards  development  efforts  with  appropriate  technical  committees  of  the 
International  Organization  for  Standardization,  and  the  International  Telegraph 
and  Telephone  Consultative  Committee  of  the  International  Telecommunication 
Union.  This  Technical  Information  Bulletin  presents  and  overview  of  an  effort 
which  is  contributing  to  the  development  of  compatible  Federal,  national,  and 
international  standards  in  the  area  of  facsimile.  It  has  been  prepared  to 
inform  interested  Federal  activities  of  the  progress  of  these  efforts.  Any 
comments,  inputs  or  statements  of  requirements  which  could  assist  in  the 
advancement  of  this  work  are  welcome  and  should  be  addressed  to:.. 
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1.0  INTRODUCTION 


This  document  summarizes  work  performed  by  Delta  Information  Systems, 
Inc.,  for  the  Office  of  Technology  and  Standards  of  the  National  Communications 
System,  an  organization  of  the  U.  S.  Government,  under  Task  2  of  contract 
number  DCA100-89-C-0078.  The  purpose  of  this  Task  was  the  modification  of  the 
Group  4  Validation  System  software  to  conform  to  the  CCITT  "Blue  Book" 
Recommendations  governing  Group  4  Facsimile  equipment. 

The  Group  4  Validation  System  was  developed  in  accordance  with  the  Open 
Systems  Interconnection  (OSI)  7-layer  architecture.  With  the  release  of  the  CCITT 
"Blue  Book"  Recommendations,  the  Application/User  interface,  the  Application 
Layer  and  the  Presentation  Layer  were  either  defined  and/or  significantly  changed. 

In  particular  the  upper  layers  of  Group  4  Facsimile  are  now  structured  in 
accordance  with  the  Open  Document  Architecture  (ODA)  and  the  Document 
Transfer  and  Manipulation  (DTAM)  procedures  as  specified  in  the  T.400  Series  of 
Recommendations.  In  addition  the  Group  4  Facsimile  User/Application  interface 
and  its  associated  DTAM  Application  Profile  is  specified  in  the  T.500  Series  of 
Recommendations.  Since  the  original  implementation  of  the  Group  4  Validation 
(NCS  TIB  85-8)  was  based  on  the  CCITT  "Red  Book"  Recommendations  which 
contained  only  the  Presentation  Layer  Recommendation,  T.73,  extensive  changes 
were  required  to  the  upper  layers  to  conform  to  the  new  Recommendations.  This 
document  supercedes  NCS  TIB  85-8. 

!n  the  following  three  sections  the  system  changes,  the  system  design  and 
the  system  operation  are  presented.  Section  2  reviews  the  modifications  required 
to  the  Group  4  Validation  System  in  order  to  meet  the  requirements  of  the  "Blue 
Book"  Recommendations.  It  also  outlines  the  software  and  hardware  design  taken 
to  satisfy  the  CCITT  Recommendations  governing  the  Telematic  Protocol  structure 
for  Group  4  Facsimile  equipment.  Section  3  discusses  in  detail  the  system  design. 
It  reviews  the  hardware  and  software  design  approaches  for  implementing  the 
Telematic  protocol  structure.  This  structure  is  consistent  with  the  seven-layer 
Open  Systems  Interconnection  (OSI)  reference  model,  which  provides  a  basic 
framework  for  protocol  development.  Section  4  details  the  operational  procedures 
of  the  validation  system  and  explains  the  parameterization  required  to  define  the 
protocol  variants  for  the  testing  of  a  Group  4  terminal.  In  the  last  section,  Section 
5,  a  review  of  the  most  recent  activity  within  CCITT  Study  Group  VII  and  the 
impact  of  this  activity  on  the  current  Group  4  Validation  System  is  presented. 

2.0  GROUP  4  VALIDATION  SYSTEM  OVERVIEW 

The  primary  purpose  of  the  Group  4  Validation  system  is  the 
testing/evaluation  of  a  Group  4  Facsimile  terminal.  Shown  in  Figure  2.1  is  a 
simplified  block  diagram  of  the  Validation  System  architecture.  The  function  of  the 
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validation  system  is  to  insure  that  the  Group  4  Facsimile  terminal  (UUT)  has 
properly  implemented  the  protocols  required  for  layers  3  through  7  of  the  Telematic 
Protocol  structure  for  Group  4  Facsimile  equipment  and  also  conforms  to  the 
allowable  parameter  variations  (e.g.  buffer  sizes,  timeout  p?riods,  etc.)  within  each 
protocol  layer.  Protocol  testing  of  layers  1  &  2  (Physical  layer  &  Link  layer)  is  not 
performed,  however  any  protocol  violations  or  nonrecoverable  errors  are  reported 
to  the  higher  layers.  The  validation  system  was  implemented  with  layers  3 
through  7  and  the  necessary  control  routines  (e.g.  test  control,  error  logging  etc) 
using  Delta  Information  System's  HP  1000  processor.  Since  this  initial 
implementation,  the  system  has  been  ported  to  an  IBM  PC  Compatible  Computer 
system.  Delta  is  in  the  process  of  testing  this  implementation. 

The  Group  4  Validation  System  software  consists  of  the  system  executive  or 
test  control  side,  the  Group  4  terminal  emulator  and  a  Group  4  Unit  Under  Test 
(UUT)  side(s).  The  system  executive  controls  the  execution  of  the  selected  test(s) 
and  verifies  that  the  Group  4  UUT  is  correctly  executing  and  responding  to  the 
test.  The  emulator  simulates  a  "model"  Group  4  terminal  and  performs  all 
operations  as  requested  by  the  validator.  A  system  comparator  compares  the 
results  of  the  model  and  the  UUT  insuring  correct  operation.  The  validation  system 
software  as  implemented  can  support  both  the  validator  and  emulator/UUT  sides 
within  the  same  processor  for  testing  or  two  separate  processors  to  demonstrate 
the  final  system  operation.  The  software  for  the  validation  system  was  written  in 
Fortran  77  to  maximize  its  transportability  between  operating  systems.  The 
software  design  and  development  was  done  using  top-down  structured  techniques. 
This  design  approach  yields  software  which  is  highly  modular  and  easy  to  modify. 
This  modularity  has  also  facilitated  changes  to  the  software  required  by  the 
evolving  CCITT  Recommendations. 

The  original  Group  4  Validation  System  development  was  based  on  the  1984 
CCITT  "Red  Book"  Recommendations.  Shown  in  Figure  2.2  are  the  CCITT 
Recommendations  by  ISO  layer  as  defined  at  that  time.  With  the  release  of  the 
1988  CCITT  "Blue  Book"  Recommendations,  the  upper  layers  of  the  Group  4 
Facsimile  7  iayer  stack  have  undergone  substantial  change.  Shown  in  Figure  2.3 
are  the  CCITT  Recommendations  by  ISO  layer  within  the  current  Group  4 
Validation  System.  Since  at  the  time  of  the  original  Group  4  Validation  System 
implementation  no  recommendations  existed  governing  the  User  and  Application 
Layer,  significant  work  was  required  in  order  to  align  the  Validation  System 
software  with  the  new  CCITT  recommendations. 

2.1  User  Layer/Application  Layer  Interface  Modifications 

With  the  release  of  the  CCITT  "Blue  Book"  Recommendations,  the 
User/Application  Layer  Interface  is  structured  in  accordance  with  the  Open 
Document  Architecture  (ODA)  and  the  Document  Transfer  and  Manipulation 
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(D7AM)  procedures.  In  particular  the  Application  Layer  Service  definition  is  now 
defined  in  CCITT  Recommendation  T.432,  )ocument  Transfer  and  Manipulation 
Service  Definition  and  the  DTAM  Application  Profile  for  Group  4  Facsimile  Class  1 
is  defined  in  the  T.500  Recommendations. 

The  DTAM  Application  Profile  is  comprised  of  the  following 
recommendations: 

T.521  -  Communication  Application  Profile  BTO  for  Document 

Bulk  Transfer  based  on  the  Session  Service  (According  to 
T.62bis). 

T.503  -  Document  Application  Profile  for  the  Interchange  of 
Group  4  Facsimile. 

T.563  -  Terminal  Characteristics  for  Group  4  Facsimile  Apparatus. 

Recommendations  T.503  and  T.521  define  their  respective  profiles  in  accordance 
with  the  T.410  Series  of  Recommendations  for  Open  Document  Architecture. 

The  User/Application  Layer  interface  is  now  defined  in  the  T.430  Series  of 
Recommendations  In  particular,  T.431  specifies  the  DTAM  Service  Definition  and 
the  Application  Protocol  Data  Units  (APDUs)  required  for  Group  4  Facsimile  Class  1 
devices. 

2.2  Application  Layer  Modifications 

As  with  ihe  User/Application  Layer  Interface,  there  were  no  CCITT 
Recommendations  defining  the  Application  Layer  for  Group  4  Facsimile  when 
originally  implemented.  With  the  release  of  the  CCITT  "Blue  Books",  the 
Application  Layer  is  now  governed  by  the  T.430  series  of  Recommendations. This 
series  defines  the  Document  Transfer  and  Manipulc  Ion  (DTAM)  services  and 
protocols  for  telematic  communications.  Shown  in  Figure  2.4  is  tue  Model  of 
DTAM  Service  as  difined  in  Recommendation  T.432.  There  are  two  modes  of 
operation  within  the  DTAM  model.  One  is  "Normal"  mode,  which  maps  the  DTAM 
services  on  to  the  A^’/lication  and  Presentation  Layer  Services  as  defined  in  X.217 
and  X.216  respectively.  The  second  mode  is  "Transparent"  mode,  which  the 
maps  the  DTAM  services  on  to  the  Session  Layer  Services  as  defined  in  T.62bis. 
The  Group  4  Validation  System  uses  the  "Transparent"  mode  of  the  DTAM  Model 
as  this  is  specified  in  Recommendation  T.521  which  defines  +he  Communication 
Application  Profile  for  Grouo  4  Facsimile  (See  Figure  2.3). 

The  Application  Layer  of  the  Group  4  Validation  System  now  supports  the 
Document  Transfer  and  Manipulation  Service  Definition  and  Protocol  as  defined  in 
the  T.430  Series  of  Recommendations  for  Group  4  Facsimile.  Although  not 
required  for  Group  4  Facsimile,  the  "normal"  mode  of  operation  within  the  DTAM 
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model  was  considered  in  the  design  of  layer  7  software  to  allow  for  its  inclusion  at 
a  later  date. 

2.3  Presentation  Layer  Modifications 

The  Presentation  Layer  in  the  initial  implementation  of  the  Group  4 
Validation  System  was  defined  by  CCITT  Recommendation  T.73.  With  the  release 
of  the  CCITT  "Blue  Books"  T.73  was  replaced  by  Recommendations  in  the  T.500 
Series.  The  Presentation  Service  and  Protocol  for  the  Group  4  Validation  System  is 
now  aligned  with  the  OSI  Model  and  is  governed  by  CCITT  Recommendations 
X.216  and  X.226. 

In  addition,  to  conform  to  the  Group  4  Communication  Application  Profile  in 
T.521,  necessary  modifications  have  been  made  to  the  Group  4  Validation  System 
to  include  the  ability  to  bypass  the  Presentation  Layer  and  to  map  directly  on  to  the 
Session  Service.  This  modification  is  done  also  in  compliance  to  the  new 
Recommendation  T.62bis,  which  defines  the  above  process. 

3.0  VALIDATION  SYSTEM  DESIGN 

3.1  Software  Design  Approach 

3.1.1  System  Concept 

Since  the  basis  for  Group  4  Facsimile  equipment  is  the  Telematic  protocols 
as  described  in  the  CCITT  recommendations,  listed  in  Table  3-1,  the  validation 
system  software's  primary  responsibility  is  the  implementation  and  validation  of 
these  protocols.  Along  with  this  requirement,  the  validation  system  must  also  be 
capable  of  specifying  and  testing  the  different  parameters/variables  allowed  within 
each  of  the  protocol  layers  as  defined  in  the  recommendation  for  that  layer. 

Shown  in  Figure  3.1  is  a  functional  block  diagram  of  the  validation  system 
software.  From  an  overall  point  of  view,  the  validation  system  drives  two  (2) 
operations  -  the  UUT  and  the  G4  terminal  emulator  -  and  compares  the  results. 

The  emulator  acts  as  a  "golden"  model  against  which  the  performance  of  the  UUT 
is  compared,  giving  due  allowance  for  permissible  variations  in  operation.  By 
substituting  another  instantiation  of  the  emulation  and  its  interface,  the  validation 
software  itself  can  be  tested,  with  the  help  of  both  proper  and  selected  improper 
variation  controls  applied  to  the  "UUT"  emulation.  In  operation,  the  system 
executive  functions  as  the  user  layer  (a  pseudo  layer  7.5),  along  with  the  operator 
interface  and  the  test  package  data.  An  event  queue  functions  as  the  command 
and  data  channel,  in  both  directions,  between  the  system  executive  and  the  two 
validation  instantiations;  the  queue,  in  effect,  functions  as  the  link  between  the 
software  portion  of  the  system  resident  on  the  validation  processor  and  the  UUT. 
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The  system  executive  starts  and  stops  processes,  in  response  to  commands  via 
the  operator  interface  and  completion  (successful  or  not)  indications  from  the 
validations,  and  also  examines  the  event  queue  to  determine  which  modules  to  poll 
for  action.  Each  module,  when  polled,  modifies  a  state  (or  substate)  or  moves  data 
as  appropriate;  the  comparator  is  then  called  to  determine  if  the  action  taken  was 
permissible,  via  comparison  with  the  "good"  model,  in  some  cases  forcing  the 
latter  to  match  the  actual  UUT's  (or  in  test  mode,  the  possibly  faulted  validation's) 
action,  if  a  permissible  variation. 

3. 1.1.1  Design  Philosophy 

Thoroughness  of  testing,  and  the  fineness  of  detail  in  the  results  obtained 
from  tests,  were  the  driving  principles  in  the  design  of  the  system.  This 
consideration,  reinforced  by  structured  programming  principles,  dictated  that  all 
actions  which  are  significant  (in  protocol  terms)  be  made  visible  by  small  modules. 
In  order  to  make  the  system  capable  of  maintenance  and  enhancement,  modules 
were  aligned  to  the  layering  (in  the  OSI  sense)  and  to  the  CCITT  protocol 
recommendations  which  they  implement.  In  this  way,  the  scope  of  the  system  as 
a  whole  can  be  easily  broadened,  and  modifications  to  the  CCITT  protocols  have 
been  incorporated  with  relative  ease.  Fortran  77  was  chosen  as  source  language 
for  the  validation  system  because  of  its  portability,  efficiency,  and  its  structuring 
(especially  with  MIL-STD-1753  enhancements).  Its  support  for  serially  reusable 
modules  permits,  and  redundancy/inconsistency  considerations  strongly  advise, 
modules  dedicated  to  protocol  functions  which  are  usable  by  both  the  UUT  and  the 
emulation  subsystems,  on  both  sides  of  the  interface.  Fortran's  COMMON  blocks 
are  used  to  store  states,  substates,  and  overall  status.  The  event  queue  is  used 
not  only  as  a  "mailbox"  between  modules  for  interlevel  commands,  but  also  as  a 
journal  for  the  actions  taken  by  the  UUT  and  emulations  of  it.  With  the  use  of 
multiple  linked  lists,  each  corresponding  to  a  specific  event,  maintained  by  well 
tried  "heap"  storage  management  techniques,  each  module  quickly  performs  its 
intended  function.  In  coding  the  various  modules,  strict  adherence  to  ANSI 
X3. 9-1 978  extended  by  MIL-STD-1753,  both  in  letter  and  spirit,  was  followed. 

This  policy  not  only  guarantees  relative  ease  in  porting  software  from  processor  to 
processor  but  also  guarantees  the  reusability  of  modules  as  mentioned  above. 
Module  reentrancy  was  not  relied  upon,  but  has  been  taken  advantage  of  (usually 
by  multitasking)  where  available. 

3. 1 . 1 .2  Design  Approach 

A  top-down  methodology  was  followed  in  the  software  design  of  the 
system.  The  system  itself  was  structured  as  "open-ended",  using  small  modules. 
Each  module  when  coded  was  essentially  complete,  but  those  of  its  functions 
which  were  not  needed  in  the  present  description  of  the  system  resulted  in  direct 
or  indirect  invocations  of  "stubs"  or  placeholder  modules.  When  it  is  necessary  to 
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add  a  given  function  to  the  system,  the  modules  completing  that  function  can  be 
substituted  for  the  stubs.  The  event  queue  approach  was  chosen  to  bring  as  many 
protocol  actions  as  feasible  out  into  the  open,  where  the  performance  of  the  UUT 
can  be  compared  in  detail  with  a  properly  acting  model  supposedly  compatible  with 
it.  It  permits  detailed  error  reports  which  not  only  back  up  invalidity  decisions  but 
also  aid  the  agency  requesting  the  validation,  without  the  use  of 
difficult-to-implement  protocol  conformance  evaluations  in  the  large.  The  approach 
also  enhanced  the  open-endedness  of  the  system,  particularly  with  regard  to  added 
functionality  and  CCITT  recommendation  revisions.  Other  service  routines  were 
specified  and  implemented  as  the  need  for  them  became  apparent. 

3.1.2  Validation  System  Description 

From  a  functional  point  of  view,  the  validation  system  is  comprised  of  the 
following  parts: 

Operator  Interface 
Test  Package 
System  Executive 

UUT  Subsystem  and  status/buffer  stores 
Emulator  Subsystem  and  status/buffer  stores 
UUT/Emulator  Comparator 
Event  queue  and  allied  management  software 

The  following  details  the  part  played  in  the  operation  by  each  of  these 
subsystems. 

3. 1.2.1  Operator  Interface 

This  set  of  modules  provides  the  means  by  which  specific  tests  can  be 
selected  and  initiated,  and  the  results  of  tests  returned,  in  the  form  and  in  detail 
requested  by  the  operator.  It  also  provides  the  operator  step-by-step  instructions 
for  normal  UUT  validations,  including  selection  of  alternate  protocols  where 
appropriate.  For  maintenance  and  diagnostic  purposes,  the  operator  may  also 
choose  between  parallel  and  serial  UUT  and  emulation  operation,  and  may  also 
compare  a  selectively  faulted  emulation  with  an  unfaulted  model.  Internal  to  the 
system,  this  subsystem  maintains  a  table  of  testing  options,  and  calls  the  system 
executive  to  start,  resume,  or  wrap  up  a  test  as  instructed. 

3.1 .2.2  Test  Package 

While  no  modules  are  strictly  part  of  the  test  package,  this  must  be 
considered  part  of  the  system  as  a  whole.  This  package  will  normally  reside  on 
auxiliary  storage,  and  can  be  easily  substituted  for  special  purposes.  Basically,  it 
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consists  of  test  data  for  transmission,  plus  control  information  for  selecting  modes 
of  operation  on  various  levels.  These  modes  include  not  only  permissible 
alternatives  but  also  invalid  ones  to  test  the  UUT's  capability  to  react  properly  to 
protocol  errors. 

3. 1.2. 3  System  Executive 

When  invoked  by  the  operator  interface,  the  system  executive  initiates  the 
selected  task  by  obtaining  testing  information  from  the  test  package,  storing  it  and 
initializing  the  event  queue  as  appropriate.  Thereafter,  it  polls  the  linked  lists 
which  make  up  the  event  queue  and  calls  the  appropriate  modules  to  take  action. 
On  test  completion  or  an  abort  condition  signaled  by  the  comparator  subsystem, 
the  general  nature  of  the  test  result  is  passed  to  the  operator  interface,  so  that 
detailed  test  result  data  can  be  printed  or  otherwise  provided.  Executive  polling 
can  be  done  in  two  ways,  roughly  describable  as  parallel  and  serial.  In  the  parallel 
mode,  the  UUT  and  the  emulation  are  kept  essentially  in  step  with  one  another;  the 
UUT  is  blocked  from  getting  more  than  a  single  significant  protocol  event  ahead  of 
the  emulation.  In  this  mode,  the  UUT  does  not  proceed  to  step  N  +  1  until  the 
emulator  has  taken  step  N  and  its  action  compared  with  the  corresponding  UUT 
step.  This  mode  is  particularly  useful  for  detailed  examination  of  operation, 
especially  in  debugging.  The  serial  mode,  on  the  other  hand,  allows  UUT  actions 
to  have  priority  over  emulation  actions,  letting  the  UUT  "run  free",  so  to  speak. 

The  emulator,  and  the  comparison  of  its  actions  with  the  UUT,  are  handled  as  time 
is  available,  using  the  event  queue  as  the  UUT  "history"  medium.  Serial  mode  may 
be  required  for  some  terminals  and  modes  of  operation;  for  emulation-to-emulation 
comparisons,  the  parallel  mode  is  obviously  preferable. 

3. 1.2. 4  UUT  Subsystem 

This  subsystem  consists  of  a  set  of  modules,  shared  with  the  emulator 
subsystem,  which  implement  the  protocols  and  functions  called  for  at  each  layer  of 
the  OSI  model.  What  actually  dedicates  it  to  the  UUT  (or  an  emulation  of  one)  is 
the  functional  incorporation  of  the  UUT  and  its  hardware  interface  into  the  system, 
and  the  stored  status,  buffers,  and  linked  lists  specifically  associated  to  the  UUT  or 
its  standin.  The  procedure  modules,  as  such,  function  as  routines  dedicated  to 
their  protocol  implementation  and  transmission  functions,  rather  than  that  of 
interfacing  to  the  UUT  or  providing  a  control  against  which  the  UUT  performance 
can  be  evaluated. 

Each  module  performs  one  or  more  actions  corresponding  either  to 
protocol-specified  change  of  state  or  substate,  or  performs  inter-layer  translation 
functions.  A  module  is  thereby  identified  with  specific  sections  or  subsections  of 
the  protocol  recommendation  which  it  implements;  its  actions,  rather  that  being 
"hard-coded",  are  driven  by  a  decision  table  closely  reflecting  the  "state  diagrams" 
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(when  available)  included  with  the  CCITT  recommendations,  even  to  the  state 
numbers  and  other  annotation.  The  decision  tables,  fixed  at  compile  time,  are 
supplemented  by  parallel  mask  and  vector  tables  which  can  modify  actions  either 
to  reflect  alternative  actions  or  transmission  paths,  or  to  force  improper  actions  to 
be  taken,  either  to  test  the  UUT's  reaction  to  them,  or  for  debugging  purposes, 
especially  in  emulation  vs  emulation  tests.  These  supplementary  tables  are 
modified  during  execution  to  implement  alternate  protocol  choices,  hardware  vs 
software  module  implementations,  and  "error-force"  option  selections. 

The  heart  of  the  UUT  subsystem,  as  such,  is  the  stored  data  which  reflects 
the  current  states  and  substates  of  the  UUT  transmission  in  progress,  the  linked 
lists  containing,  by  layer  and  direction,  the  history  of  the  transmission,  and  the 
transmitted  data  itself.  Substates,  as  far  as  the  software  is  concerned,  simply 
provide  a  more  detailed  description  that  the  CCITT-defined  states  as  such;  the 
designation  was  chosen  to  keep  the  coarser  states  in  line  with  the  CCITT 
specifications.  Relative  to  states,  substates  record  such  details  as  timeout  counts, 
intermediate  status  in  combine/divide  operations,  and  other  data  needed  to  define 
fully  the  status  of  a  given  transmission. 

The  linked  lists  provide  the  main  mechanism  by  which  the  protocol  modules 
communicate  with  one  another.  In  operation,  the  executive  polls  all  linked  lists  for 
unhandled  events;  when  one  is  found,  the  appropriate  protocol  module  "handles" 
the  event,  usually  marks  it  as  "done"  and  places  another  event  on  another  linked 
list  for  some  other  module  to  handle,  modifying  the  stored  status  accordingly.  In 
cases  where  the  correspondence  between  "input"  and  "output"  events  is  not 
one-to-one,  the  module  may  delay  "signing  off"  on  the  input  event  or  placing 
another  event  on  its  own  input  linked  list  as  is  appropriate,  to  guarantee  that  is  be 
polled  to  complete  its  function.  In  any  case,  the  action  taken  by  a  protocol  module 
on  one  invocation  is  scaled  down  to  a  maximum  of  one  event  in  or  out. 

3. 1.2. 5  Emulator  Subsystem 

The  emulator  subsystem  shares  all  its  protocol  procedure  modules  (except 
where  replaced  by  hardware/firmware  links)  with  the  UUT  subsystem;  the 
difference  is  in  the  status  and  buffer  stores  dedicated  to  the  subsystem,  the  linked 
lists  which  provide  layer  interfaces,  and  the  method  by  which  supervisory  control 
over  it  is  exercised.  Each  protocol  module  is  ignorant  whether  it  is  performing  its 
function  for  the  UUT  emulator,  but  is  provided  with  the  status  tables,  linked  lists, 
etc.,  peculiar  to  one  or  the  other  by  the  calling  executive.  The  basic  decision 
tables  used  are  the  same  as  for  the  UUT,  but  supplementary  mask  and  vector 
tables  may  differ,  according  to  the  purpose  of  particular  tests,  and  the  double  use 
of  emulator  modules  on  both  the  DTE  and  DCE  sides  of  the  transmission,  for 
example  when  the  effect  of  one  sided  protocol  errors  are  being  tested.  The 
difference  in  supervisory  control  is  implemented  by  the  comparator  subsystem, 
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working  with  the  executive,  as  described  below. 

3. 1.2. 6  UUT/Emulator  Comparator 

The  job  of  the  comparator  subsystem  is  to  keep  the  UUT  and  emulator 
systems  in  line  with  another,  comparing  their  actions  on  an  event  by  event  basis, 
and  reporting  on  serious  discrepancies.  In  order  to  do  this,  actions  taken  by 
protocol  modules  on  both  sides  are  "filtered"  through  a  comparator  module  which 
takes  differential  actions,  depending  on  the  "side"  from  which  the  action 
emanates.  On  the  UUT  side,  in  serial  mode  actions  are  allowed  to  proceed;  in 
parallel  mode,  an  action  may  be  held  up  until  the  emulator  side  has  reacted  to  the 
corresponding  stimulus.  This  is  accomplished  by  the  protocol  module  placing  its 
generated  events  on  the  comparator  module's  stimulus  list;  the  comparator  will 
pass  it  on  (by  relinking)  when  and  if  appropriate.  Once  both  sides  have  reacted  to 
corresponding  stimuli,  results  are  compared.  If  they  match,  the  process  is  allowed 
to  continue  with  no  special  action  being  taken.  If  the  action  taken  by  the  UUT  side 
is  a  valid  alternative  to  that  of  the  emulator,  the  latter's  action  is  modified  to  match 
the  UUT.  Otherwise,  an  error  report  is  generated  and  the  entire  process  is  aborted 
or  modified  and  force  to  continue  as  is  appropriate  to  the  seriousness  of  the  error 
and  pertinent  operational  modes  as  set  by  the  operator. 

In  cases  where  only  one  side  is  c  software  module  whose  stimuli  and 
responses  are  available  to  the  comparator  (for  example,  the  DTE-end  emulator 
paralleled  to  the  UUT  itself),  no  attempt  is  made  to  keep  actions  in  line.  Instead, 
the  "small"  actions  on  the  "soft"  side  are  assumed  to  match  the  other  side,  and 
alignment  and  comparison  are  deferred  to  a  layer  where  both  sides  are  available. 

No  error  reports  are  generated  where  mismatches  can  not  be  diagnosed,  of  course; 
however,  the  comparator  subsystem,  through  suitable  interface  modules,  will 
merge  error  detections  passed  on  by  hardware/firmware  modules  into  the  same 
error  report  list  used  by  software/software  mismatch  reports. 

3. 1.2. 7  Event  Queue  and  Associated  Management  Facilities 

Although  each  event  "belongs"  to  a  specific  side,  layer,  and  module  at  any 
given  time,  its  structure  is  common  to  the  overall  process  itself.  Storage  for  each 
event  is  allocated  in  space  available  to  all  modules,  via  common  allocation/garbage 
collection  routines.  For  auditing  purposes,  all  events  are  linked  by  time  of 
generation;  for  functional  purposes,  a  second  linkage  is  used  to  connect  them  with 
previous  and  successive  events  at  the  same  and  neighboring  layers.  This  latter 
connection  is  modified  (by  relinking)  by  comparator  modules  in  order  to  let  a 
process  continue  or  to  "roll  back"  a  given  action. 

Each  event  contains,  at  a  minimum,  the  following  information: 
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(1)  An  indication  of  the  nature  of  the  event,  including  codes  for  layers 
involved; 

(2)  An  indication  of  the  "side"  (UUT  vs.  emulation),  "end"  (DCE  vs.  DTE), 
and  direction  of  the  event; 

(3)  Clock  time  for  the  event; 

(4)  List  linkages  (on  time  and  functional  bases); 

(5)  Linkages  to  data,  where  appropriate; 

(6)  Indications  of  state  changes  associated  with  the  event. 

Associated  with  the  event  queue  is  not  only  the  allocation  routines 
mentioned  above,  but  also  other  service  routines  performing  such  tasks  as  relinking 
lists  and  similar  functions.  A  real  time  clock  of  adequate  precision  is  used  to 
provide  event  timing  for  timeout  sequences  and  similar  functions.  Similarly,  for 
reporting  purposes,  routines  are  required  for  editing  compact  error  reports  from  the 
comparator  subsystem  into  terms  the  operator  can  recognize. 

3.2  Validation  System  Software  Structure 

Shown  in  Figure  3.2  is  a  block  diagram  of  the  validation  system  software. 
The  system  software  was  divided  into  3  major  components:  protocol  processing 
routines,  test  selection  and  configuration  routines  and  event  processing  routines. 

A  fourth  group  of  routines  which  are  seen  at  the  bottom  center  of  Figure  3.2  are 
the  system  service  routines.  These  routines,  as  indicated  by  their  names,  support 
those  functions  within  the  system  software  that  are  required  by  the  three  major 
components  listed  above. 

3.2.1  Telematic  Protocol  Processing  Routines 

The  protocol  processing  routines  are  those  routines  which  implement  the 
intra  layer  communication  (e.g.  layer  4  to  layer  4  peer  protocol)  and  the  inter  layer 
communication  (e.g.  layer  4  to  layer  3  service  primitives)  as  established  for  the 
Open  Systems  Interconnection  (OSI)  seven  layer  architecture  (Figure  3.3).  Located 
between  each  of  the  protocol  processing  routine  layers  are  translator  routines  (i.e. 
half  layer  routines)  which  perform  all  interlayer  translation  required. 

Since  the  Telematic  Protocol  structure,  as  shown  in  Figure  3.4,  is  based  on 
the  OSI  architecture,  the  protocol  processing  routine  are  structured  accordingly. 
The  Telematic  Protocols  can  be  divided  into  two  groups,  one  group  containing  the 
transport  protocol  (layers  1-4),  and  the  other  group  containing  the  user-oriented 
protocols  (layers  5-7). 

3. 2. 1.1  User-Oriented  Protocols 

The  user-oriented  protocols  are  provided  in  layers  five,  six,  and  seven.  These 
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layers  provide  organized,  synchronized,  meaningful  information  exchange. 

3. 2. 1.1.1  User  Layer 

The  user  layer  can  be  viewed  as  part  of  tne  Application  layer  that  initiates 
activities  to  the  sublayers  below.  Its  main  responsibility  is  to  establish  the 
information  required  for  the  application  protocol  data  units  as  defined  in  the  T.500 
series  of  recommendations  for  a  Group  4  Facsimile  Document  Application  Profile. 

Its  second  responsibility  is  the  transfer  of  this  information  via  the  DTAM  service 
definition  in  recommendation  T.431. 

3.2.1 .1 .2  Application  Layer  -  Layer  7 

The  Application  Layer  is  defined  in  the  T.400  Recommendations  series 
which  specifies  an  integrated  approach  to  facilitate  the  interconnection  of  telematic 
systems  and  terminals.  The  services  and  protocols  available  within  the  Application 
Layer  are  specified  in  a  Document  Transfer  and  Manipulation  model  (DTAM)  which 
are  defined  in  the  T.430  series  of  recommendations.  The  primary  function  of  these 
DTAM  services  are  to  provide  some  general  communication  facilities  for  document 
handling  or  handling  of  any  other  information  entities  that  can  be  treated  as 
documents,  and  which  may  be  stored  within  the  open  systems  or  accessed, 
transferred  and  manipulated  between  Application  processes.  DTAM  can  operate  in 
either  the  Transparent  Mode  or  Normal  Mode.  These  operation  modes  indicate 
where  the  DTAM  protocol  is  to  be  mapped  onto  the  lower  layers.  In  Transparent 
Mode,  the  DTAM  protocol  is  mapped  directly  onto  the  Session  Layer  services, 
whereas  in  the  Normal  Mode  mapping  is  to  be  done  onto  the  Application  layer  and 
Presentation  layer  services.  An  overview  of  the  DTAM  structure  can  be  seen  in 
Figure  3.5.  Here,  the  DTAM  user  is  responsible  for  interpreting  intentions  of  the 
actual  telematic  user  in  communication  and  performing  the  applications  (documant 
bulk  transfer,  document  manipulation,  document  transfer,  etc.)  through  support 
provided  by  the  DTAM  functional  units. 

An  introduction  and  the  general  principles  of  the  DTAM  services  and 
protocols  are  provided  in  T.431,  where  the  definitions  are  given  in  T.432  and 
T.433  respectively.  Shown  in  Figure  3.P  is  a  visual  table  of  contents  (VTOC)  for 
layer  7. 

3.2. 1 . 1 .3  Presentation  Layer  -  Layer  6 

The  previous  function  of  the  presentation  layer  was  to  define  the 
characteristics  of  the  structure  of  the  information  that  user  wish  to  exchange.  But, 
at  present  the  presentation  layer  only  acts  as  a  pass-through  from  the  application 
to  the  session  layer.  The  information  previously  defined  in  T.73  has  been  moved 
to  the  T.500  series  of  recommendations  governing  the  DTAM  Aptlication  Profile 
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LAYER  7  VTOC 


for  Group  4  Facsimile.  Figure  3.7  shows  the  VTOC  for  layer  6  when  not  used  as  a 
pass-through  layer. 

3.2.1 .1 .4  Session  Layer  -  Layer  5 

The  session  layer  is  responsible  for  setting  up,  managing  and  tearing  down 
process-to-process  connections  including  document  synchronization  and  recovery. 
The  protocol  for  this  layer  is  defined  by  Recommendation  T.62bis  which  includes  a 
"session"  part  and  "document"  part.  It  is  convenient  to  treat  both  of  these  as  an 
integral  session  layer  protocol.  The  session  establishment  function  includes 
negotiation  of  parameters  such  as  session  profile,  window  size  for  checkpoints, 
and  whether  facsimile  or  mixed  mode.  Session  establishment  is  followed  by 
information  exchange  using  the  protocol  element  "Command  Session  User 
Information"  (CSUI).  Orderly  session  release  is  also  initiated  by  command. 

One  of  the  main  tasks  of  the  session  layer  is  to  allow  the  structuring  of  the 
exchange  of  data  into  series  of  dialogue  units  which  are  isolated  from  one  another 
by  means  of  major  synchronization  points.  The  Communication  document  can 
generally  be  interpreted  as  a  dialogue  unit.  Further  synchronization  marks  can  be 
inserted  within  a  dialogue  unit  to  provide  resumption  points  for  a  broken  unit. 

These  minor  synchronization  points  are  known  as  checkpoints.  (End-of-page  is  an 
example.)  The  session  layer  also  provides  the  mechanisms  required  for  a  reset  in  a 
defined  state  or  a  restart  at  a  specific  checkpoint.  A  detailed  VTOC  for  layer  5  is 
shown  in  Figure  3.8. 

3. 2. 1.2  Transport  Protocols 

3. 2. 1.2.1  Transport  Layer  -  Layer  4 

The  transport  layer  service  is  implemented  according  to  CCITT 
Recommendation  T.70.  The  object  of  the  transport  layer  is  a  network-independent 
transparent  transfer  of  data  between  systems.  This  layer  serves  as  a  bridge 
between  the  services  performed  by  the  network  layer  (3)  and  the  services  required 
by  the  session  layer  (5).  It  must  hide  all  the  details  of  the  communication  subnet 
from  the  session  layer,  so  that  for  example,  a  point-to-point  subnet  can  be  replaced 
by  a  satellite  link  without  affecting  the  session,  presentation,  or  application  layers. 
In  addition  to  transport  connection  establishment,  option  negotiations  and 
indication  of  procedural  errors,  the  main  function  of  layer  4  is  segmentation.  That 
is,  in  the  data  transfer  phase  the  session  layer  passes  on  logically  contiguous  data 
blocks  of  unspecified  length  to  the  transport  layer.  The  transport  layer  divides 
these  blocks  into  blocks  of  predetermined  length  suitable  for  transmission  while 
preserving  their  order,  Shown  in  Figure  3.9  is  the  VTOC  for  layer  4. 
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3.2.1 .2.2  Network  Layer  -  Layer  3 

The  Network  Layer  service  is  implemented  according  to  CCITT 
Recommendation  X.25.  The  network  layer  provides  the  means  to  establish, 
maintain  and  terminate  connections  between  systems  containing  communicating 
application  processes.  The  basic  layer  service  of  the  network  layer  is  to  provide 
the  transparent  transfer  of  all  data  submitted  by  the  transport  layer.  The  network 
layer  is  assumed  to  contain  functions  necessary  to  mask  the  differences  in  the 
characteristics  of  different  transmission  and  network  technologies  into  a  consistent 
network  layer  service.  A  VTOC  for  layer  3  is  presented  in  Figure  3.10. 

3.2.1 .2.3  Link  &  Physical  Layers  -  Layer  2  &  1 

Both  of  these  layers  were  implemented  in  hardware  as  described  in  previous 
sections. 

3.2.2  Protocol  Translation  Routines 

In  the  CCITT  Recommendation,  protocols  are  described  as  between  two 
terminals  on  the  same  layer;  the  inter  layer  communication  is  usually  only  implied. 
The  validation  system  protocol  modules  follow  this  organization;  they  communicate 
with  their  own  layer  on  the  other  side  of  the  transmission  in  terms  of  the  protocol 
for  their  own  layer,  but  also  perform  the  translation/conversion  between  it  and  the 
next  higher  layer.  This  translation/conversion  is  done  by  the  translator  routines 
(half  layer  routines)  for  each  protocol  layer.  These  routines  thereby  allow  the 
protocol  processing  routines  to  be  concerned  with  only  the  implementation  of  the 
protocol  for  that  layer  and  not  any  of  the  repackaging  tasks  required  for  the 
interlayer  communication.  Shown  in  Figures  3.1 1  through  3.14  are  VTOCs  for  the 
half  layer  translation  routines. 

3.2.3  Event  Processing  Routines 

Within  the  Group  4  Validation  system  all  activity  or  communication  is 
initiated  and  processed  as  an  event.  The  event  processing  routines  control  and 
monitor  all  system  activity.  These  routines  insure  that  all  events  within  the 
validation  system  are  handled  in  the  proper  sequence  and  also  perform  the 
comparisons  necessary  for  validating  the  Group  4  UUT. 

Shown  in  Figure  3.15  is  a  VTOC  of  validation  system  event  processing 
routines. 

3.2.4  Test  Select  Configuration  Routines 

The  test  selection  and  configuration  routines  are  those  routines  that  parse, 
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VALIDATION  SYSTEM  EVENT  PROCESSING  ROUTINES 


process,  validate  and  configure  the  validation  system  for  the  currently  selected 
tests.  All  parameters  for  each  of  the  protocol  layers  are  validated  and  established 
with  an  appropriate  diagnostic  message  issued  if  a  parameter  error  is  detected. 

The  parameters  may  be  a  complete  parameter  set  defining  the  parameters  for  all 
layers  or  a  single  parameter  change  to  a  currently  existing  parameter  set.  In  this 
way  a  base  validation  test  can  be  executed  and  then  modified  by  a  single 
parameter  change  to  a  particular  layer  and  then  re-executed.  The  validation 
system  is  also  capable  of  repeating  the  currently  selected  test  if  requested  by  the 
operate. 

A  VTOC  describing  the  parameter  processing  is  shown  in  Figure  3.16.  The 
test  selection  routines  basically  read  and  parse  the  currently  selected  test,  validate 
the  test  parameters,  merge  the  new  parameters  with  any  currently  existing 
parameter^  rnd  then  configure  the  valuation  system  for  the  test. 

4.0  VALIDATION  SYSTEM  OPERATION 

The  performance  of  a  tast  by  the  validator  can  be  roughly  divided  into  five 
(5)  phases: 

-  Test  selection 

-  Test  validation 

-  Test  configuration 

-  Test  execution 

-  Test  post-mortems 

The  following  paragraphs  note  the  actions  taken  in  each  of  these  phases  and  the 
specific  inputs  and  parameters  required  for  each. 

4.1  Validation  Test  Phases 

4.  i.1  Test  Selection  Phase 

This  phase  involves  the  determination  of  the  specific  test  to  be  performed 
and  any  "special"  parameters  involved.  It  involves  the  processing  of  a  "test 
select"  file  which  names  the  test  to  be  used,  and  which  supplies  the  parameters 
unique  to  thi»  particular  performance.  The  phase  is  satisfactorily  completed  when 
the  test  name  has  been  determined  and  the  other  test  select  parameters  processed 
without  serious  errors. 

The  test  select  phase  opens  with  a  request  to  tne  operator  to  supply  the 
name  of  the  "test  select"  file.  If  the  test  involved  is  "on  file",  the  operator  supplies 
the  file  name  and  other  necessary  directory  information  at  this  time;  the  test  select 
information  in  this  file  is  then  processed.  The  operator  may  alternately  enter  a 


34 


PARAMETER  PI 


carriage  return  only,  which  causes  the  validator  to  expect  the  test  select 
information  "on  line"  from  the  operator.  In  this  case,  the  operator  types  in  test 
select  parameters,  terminating  them  with  a  dollar  sign  ($)  when  done.  See  Section 
4.2.3  for  a  description  of  test  selection  syntax. 

The  purpose  of  the  test  select  file  (as  opposed  to  the  test  file  itself)  is  to 
identify  the  test  [file]  involved  and  specify  parameters  which  supplement  or 
override  those  in  the  parameter  portion  of  the  test  file.  In  other  words,  the  test 
select  parameters  need  only  be  the  "unusual"  or  "different"  values  needed  for  a 
particular  performance.  The  test  name  may  be  specified  in  any  one  of  the 
following  forms  (see  Section  4.2.3  for  detailed  syntax)  in  the  test  select  file: 

TEST  =  'filename,etc...' 

TEST  =  * 

TEST  =  & 

The  first  form  carries  the  file  and/or  unit  identifier  for  the  test  file  to  be  used.  It 
may  also  carry  a  "version"  identifier  to  distinguish  between  multiple  tests  stacked 
in  a  single  file.  This  form  (except  as  noted  below)  indicates  that  the  named  test  is 
to  be  read  from  the  file  specified  and  its  parameters  are  to  be  used  as  the  "base" 
to  which  the  test  select  file  parameters  are  to  be  applied.  The  second  and  third 
forms  specify  that  no  test  file  "read"  is  necessary,  and  may  therefore  only  be  used 
immediately  following  successful  configuration  and  execution  of  the  specific  test  to 
be  used.  Both  use  as  "base"  the  previously  executed  test.  The  asterisk  (TEST  =  *) 
form  specifies  that  the  test  is  to  be  repeated  exactly  as  last  configured,  except  for 
the  variations  specified  in  the  test  select  file;  the  ampersand  (TEST  =  &)  form,  on 
the  other  hand,  indicates  that  the  "base"  to  which  the  test  select  parameters  are  to 
be  applied  is  the  test  as  originally  read  in,  i.e.,  the  test  restored  to  its  "default" 
condition.  For  logging  purposes,  the  "repeat"  and  "default"  options  may  also  be 
specified  using  the  first  (explicit)  form  above,  by  following  the  "TEST  = "  parameter 
by  a  "REPEAT"  or  "DEFAULT"  parameter  respectively.  For  example,  assuming  that 
the  test  just  executed  was  identified  as  "TEST1  .ABC:3", 

TEST  =  'TEST1 .  ABC:3',  DEFAULT 
is  equivalent  to 

TEST  =  & 

for  test  selection  purposes.  A  "NEW"  parameter  is  also  recognized,  to  permit 
explicit  indication  that  the  test  must  be  read  from  the  file  (in  the  validation  phase) 
before  configuration. 

Shown  on  the  following  pages  are  examples  of  both  test  selection  and  test 
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files.  On  page  38  are  listings  of  two  different  test  selection  files.  Each  test 
selection  file  consists  of  three  separate  tests  identified  by  a  version  number.  The 
first  two  tests  modify  a  single  variable  in  the  test  file  G4BASIC.TST.  The  third  test 
repeats  the  previously  executed  test  with  an  additional  variable  change.  On  pages 
39  &  40  is  a  listing  of  the  test  file  G^-BASIC.TST.  This  lest  file  is  comprised  of 
three  parts; 


-  side,  end,  and  layer  configuration 

-  layer  specific  variable  establishment 

-  test  run  data 

This  test  file  in  conjunction  with  the  changes  specified  in  the  appropriate  test 
selection  file  will  completely  define  the  validation  test  to  be  executed. 

4.1.2  Test  Validation  Phase 

Test  validation  involves  verifying  that  the  test  file  named,  if  "new",  is  in  the 
proper  form,  and  processing  its  (default)  parameters  for  later  merging  with  those 
specified  by  the  test  select  file.  If  the  "repeat"  (TEST  =  *)  or  "default"  (TEST  =  &) 
options  are  chosen,  no  validation  is  necessary  except  confirming  the  existence  of  a 
previously  configured  test.  The  success  or  failure  of  the  validation  phase  is 
indicated  by  an  appropriate  printout. 

4.1.3  Test  Configuration  Phase 

This  is  the  most  complex  of  the  three  "test  setup"  phases.  First,  the 
"repeat"  (*)  and  "default"  (&)  parameter  "values"  specified  in  the  test  select  file 
are  "filled  in"  from  the  last-executed  test  performance  or  the  "as  read  in"  test 
parameters  as  appropriate.  The  test  select  parameters  are  then  merged  with  either 
those  for  the  last  performance  (if  test  repeat  is  specified)  or  those  of  the 
"standard"  (as  read  in)  test.  Specific  test  parameters  are  then  processed,  first  the 
"global"  ones  which  must  be  first  processed,  then  tnose  "local"  to  specific  layers, 
sides,  etc.  The  layer-specific  "local"  parameters  must  include  configuration 
indications  which  specify  how  each  layer  and  half-layer  is  implemented  (e.g., 
accessible  as  software,  inaccessible  in  hardware,  an  interface  between  the  two,  or 
just  "not  there");  the  next  stage  in  the  configuration  phase  validates  that  the  layer 
to  layer  configurations  are  consistent.  Finally,  any  "leftover"  parameters  are 
processed  and  reported  on. 

Each  stage  in  the  configuration  phase  can  detect  and  classify  errors  as 
"serious"  (i.e.,  fatal)  or  "possible"  (nonfatal).  At  the  conclusion  of  the  phase, 
summary  counts  of  the  two  error  types  are  reported.  If  no  fatal  errors  have  been 
detected,  the  operator  is  asked  whether  the  test  is  to  proceed  to  the  execution 
phase.  If  the  reply  is  affirmative,  successful  configuration  of  the  test  is  reported, 
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TEST  SELECTION  FILE  EXAMPLES 
Name:  G4LYR5MOD . SEL 

Function:  To  execute  the  Grout  4  Validation  System  Base  test  with 

modifications  to  the  Session  Layer  (5)  Inactivity  timer 
(CT1T)  and  Window  Size  (CWSZ) 

File  Contents 

$TEST_SELECTION  V=2.04.01 

TEST=G4BASIC.TST  V=1.00.00  1  G4  VALIDATION  BASE 

SIDE= ( EMUL ,  END= ( BOTH ,  LAYER=( 5 ,  CT1T=45 ) ) )  i  change  timer 
SIDE* ( UUT ,  END= ( TEST ,  LAYER= ( 5 ,  CT1T-45)))  1  value 

$ 

$TEST_SELECTION  V=2.04.02 

TEST=G4BASIC . TST  V=1.00.00  l  G4  VALIDATION  BASE 

SIDE= ( EMUL ,  END= ( BOTH ,  LAYER=(5,  CWSZ=2)))  !  change  window 

SIDE* ( UUT ,  END* ( TEST ,  LAYER= ( 5 ,  CWSZ=2)))  1  size  value 

? 

$TEST_SELECTION  V=2.04.03 

TEST**  1  G4  BASE  WITH  CWSZ=2 

SIDE= ( EMUL ,  END* ( BOTH ,  LAYER=(5,  CT1T=45)))  1  change  timer  value 

SIDE= ( UUT ,  END* ( TEST ,  LAYER* ( 5 ,  CT1T=45 ) ) )  i  using  prev  test 

$ 


Name :  G4LYR3MOD . SEL 

Function:  To  execute  the  Group  4  Validation  System  Base  test  with 

modifications  to  the  Network  Layer  (3)  Data  Packet  Size 
(CDPS)  and  Use  Delivery  Confirm  (QUDC). 

File  Contents 

$TEST_SELECTION  V*2.04.01 

TEST=G4BAS IC . TST  V*1.00.00  1  G4  VALIDATION  BASE 

3  IDE=  ( EMUL ,  END33  ( BOTH ,  LAYER*  {  3  ,  CDPS=256)))  1  change  data 
SIDE* ( UUT i  END* ( TEST ,  LAYER* ( 3 ,  CT1T*256)))  l  packet  size 
$ 

?TEST_SELECTION  V*2.04.02 

TEST*G4BASIC . TST  V*1.00.00  l  G4  VALIDATION  BASE 

SIDE* (EMUL,  END* (BOTH,  LAYER* ( 3 ,  QUDC=Y) ) )  1  change  to  use 

SIDE* ( UUT ,  END* ( TEST ,  LAYER* ( 3 ,  QUDC*Y) ) )  1  delivery  confirm 

$ 

$TEST_SELECTION  V=2.04.03 

TEST**  1  G4  BASE  WITH  QUDC*Y 

SIDE=( EMUL,  END* ( BOTH ,  LAYER* ( 3 ,  CDPS=256)))l  change  packet  size 
SIDE* ( UUT ,  END* ( TEST ,  LAYER* ( 3 ,  CDPS=256)))  1  using  prev  test 

$ 
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Name:  G4BASIC . TST 

Function:  To  define  the  side,  end  and  layer  configuration  for  the 
Group  4  Validation  System  Base  Test.  It  also  defines 
the  default  values  for  the  layer  specific  variables  as 
established  in  the  CCITT  T  &  X  Recommendations  for  Group 
4  Facsimile. 


File  Contents 
$TEST_PARAMETERS 

j 

!  establish  side,  end  and  layer  conf iguration 


SIDE*  (EMUL, 

END* 

( BOTH , 

LAYER- 

(u. 

CNFIG-S) 

)  ) 

SIDE*  (EMUL, 

END- 

(BOTH, 

LAYER* 

(7, 

CNFIG—S ) 

)  ) 

SIDE*  (EMUL, 

END* 

(BOTH, 

LAYER- 

(G, 

CNFIG-S) 

)  ) 

SIDE*  (EMUL, 

END- 

( BOTH , 

LAYER* 

(6, 

CNFIG-S) 

)  ) 

SIDE*  (EMUL, 

END* 

( BOTH , 

LAYER- 

(F, 

CNFIG-S) 

)  ) 

SIDE*  (EMUL, 

END- 

( BOTH , 

LAYER* 

(5, 

CNFIG-S) 

)  ) 

SIDE*  (EMUL, 

END* 

( BOTH , 

LAYER- 

(E, 

CNFIG-S) 

)  ) 

SIDE*  (EMUL, 

END- 

( BOTH , 

LAYER* 

(4, 

CNFIG-S) 

)  ) 

SIDE*  (EMUL, 

END* 

( BOTH , 

LAYER- 

(D, 

CNFIG-S) 

)  ) 

SIDE*  (EMUL, 

END* 

(BOTH, 

LAYER* 

(3, 

CNFIG-S) 

)) 

SIDE* 

(UUT, 

END- 

(NEAR, 

LAYER- 

(U, 

CNFIG—S ) ) ) 

SIDE- 

(UUT, 

END* 

(NEAR, 

LAYER* 

(7, 

CNFIG-S ) ) ) 

SIDE* 

(UUT, 

END- 

( NEAR , 

LAYER- 

(G, 

CNFIG-S ) ) ) 

SIDE- 

(UUT, 

END* 

(NEAR, 

LAYER- 

( 6 , 

CNFIG-S) ) ) 

SIDE* 

(UUT, 

END- 

(NEAR, 

LAYER- 

(F, 

CNFIG-S) ) ) 

SIDE- 

(UUT, 

END* 

(NEAR, 

LAYER* 

(5, 

CNFIG-S) ) ) 

SIDE* 

(UUT, 

END- 

(NEAR, 

LAYER- 

(E, 

CNFIG-S) ) ) 

SIDE- 

(UUT, 

END* 

(NEAR, 

LAYER* 

(4, 

CNFIG=S ) ) ) 

SIDE* 

(UUT, 

END- 

(NEAR, 

LAYER* 

(D, 

CNFIG-S) ) ) 

SIDE* 

(UUT, 

END* 

(NEAR, 

LAYER* 

(3, 

CNFIG-S) ) ) 

1 

1  establish  layer  specific  variables 
!  using  T  &  X  recommendation  defaults 
1 

SIDE*  (UUT,  END-  (NEAR,  LAYER*  (6,  HBTC-2,  HICF-0,  HPGDW, 10200 

HPGDL-13200,  HPTD-200))) 

SIDE*  (EMUL,  END-  (BOTH,  LAYER*  (6,  HBTC=2,  HICF=0,  HPGDW, 10200 

HPGDL=13200 ,  HPTD*200 ) ) ) 

SIDE*  (UUT,  END*  (NEAR,  LAYER*  (5,  CT1T-60,  CT2T=60,  CT3T=4, 

QCTU-N,  QAER=N ,  QUYO-N 

QULL=N ,  QRA J =N ,  CMSZ-3,  CWSZ*3, 

PBLFCTD-256,  PBLFCTU=256 ) ) ) 

SIDE*  (EMUL,  END*  (BOTH,  LAYER*  (5,  CT1T=60,  CT2T-60,  CT3T-4, 

QTCU*N ,  QAER=N ,  QUYO=N, 

QULL=N ,  QRAJ-N,  CMWZ-3,  CWSZ=3, 
PBLFCTD=256 ,  PBLFCTU-256 ) ) ) 
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SIDE*  (UUT,  END*  (NEAR,  LAYER*  (4,  C02A=45,  C03B=6,  C11C=45, 

C11R=5,  C11T=225 ,  CBRM=2, 

CBAM=2,  CUBS=7,  CMBE=7, 
PBLFCTD=128,  PBLFCTU=128, 

QANC=Y ,  QATC=Y,  QTXP=Y, 

QTRY=Y ,  CTCC=0 ,  CREF* ' LOCREF ' ) ) ) 
SIDE=  (EMUL,  END=  (BOTH,  LAYER=  (4,  C02A=45,  C03B=6,  C11045. 

Cl 1R=5 ,  C11T=225 ,  CBRM=2, 

CBAM=2,  CUBS=7,  CMBE=7 , 
PBLFCTD=128 ,  PBLFCTU=128, 

QANC=Y,  QATC=Y,  QTXP=Y, 

QTRY=Y,  CTCC=0 ,  CREF* ' LOCREF ')) ) 
SIDE=  (UUT,  END=  (NEAR,  LAYER*  (3,  CDPS=128,  QXPS=N,  QUDC*N, 

CHNGRPD=0 ,  CHNGRPU=0, 

CHNNUMD=0 ,  CHNNUMU=0 ) ) ) 

SIDE*  (EMUL,  END*  (BOTH,  LAYER*  (3,  CDPS=128,  QXPS=N,  QUDC=N, 

CHNGRPD=0 ,  CHNGRPU=0, 

CHNNUMD=0 ,  CHNNUMU=0 ) ) ) 


$TEST  RUN  DATA 


i  actual  test  run  data 


/QUEUE 

E7AACQ 

L=7UN 

HPND 

S*0<0/0 

/QUEUE 

E7AACQ 

l 

f 

1 

1 

1 

y 

L=7CN 

HPND 

S*0<0/0 

/EVENT 

E7AAIQ 

L=  7  UN 

HPND 

D* - 

/EVENT 

E7AAIQ 

L=7CN 

HPND 

D* - 

I 

I 

I 

I 

/END  PRINT  PURGE 
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and  the  stage  is  set  for  test  execution.  However,  if  fatal  errors  have  been 
detected,  or  the  operator  has  responded  negatively  to  the  request  to  proceed, 
configuration  failure  is  reported,  and  status  is  returned  (as  far  as  possible)  to  that 
prior  to  test  selection. 

Generally,  errors  are  classified  as  "serious"  if  the  test  cannot  reasonably 
executed  under  the  values  (or  lack  of  them)  specified  by  the  particular  parameter 
causing  the  error.  "Possible"  errors,  on  the  other  hand,  are  usually  those  for  which 
the  module  concerned  can  specify  a  reasonable  "default"  value  (which  it  reports), 
or  simply  a  (possibly  misspelled  or  misplaced)  parameter  which  it  cannot  recognize. 
The  many  handling  modules  themselves  are  responsible  for  the  classification  of  the 
various  errors  involved.  There  is,  however,  a  class  of  serious  errors  which  can  be 
specified  in  the  parameter  portion  of  the  test  file  itself.  The  test  file  can  indicate 
that  the  test  select  file  must  not  override  certain  parameter  values,  and  a.so  require 
the  test  select  file  to  supply  certain  parameters.  For  specifics,  see  the  FIXED, 
REQUIRED,  and  OPTIONAL  parameters  in  Section  4.2.5,  but  briefly  it  works  like 
this: 


...,REQUIRED  =  ( . ),... 

indicates  that  a  serious  error  will  be  detected  if  the  test  select  file  fails  to  supply 
any  parameters  named  within  the  parentheses; 

..., FIXED  =  ( . ),... 

indicates  that  any  attempt  to  override  parameters  named  within  the  parentheses 
will  be  diagnosed  as  a  fatal  error;  and 

..., OPTIONAL  =  ( . ),... 

restores  the  options  of  supplying  and/or  overriding  the  parenthesized  parameters  as 
appropriate  to  the  particular  module  or  modules  concerned. 

4.1.4  Test  Execution  Phase 

This  phase  involves  initialization  of  global  and  layer-specific  status  to 
"startup"  condition,  preparation  of  the  test  "script"  (run  data)  for  processing,  and 
finally  transfer  of  control  to  event-driven  test  execution.  Global  initialization 
involves  setting  the  event  queue  "empty"  (ready  to  receive  events),  and  resetting 
test-level  status  indicators.  Initialization  of  the  various  layer/side/end  combinations 
depends  on  how  each  is  configured. 

For  a  layer/side/end  combination  configured  via  a  protocol  or  translator 
module  (accessible  from  both  "upward"  and  "downward"  directions),  it  is 
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necessary  only  to  reset  its  status  to  "startup"  condition.  For  an  interface 
combination,  however,  in  which  one  of  the  vertical  directions  is  "blocked"  (i.e., 
inaccessible  because  implemented  in  hardware),  it  is  necessary  to  install  a  "poll" 
event,  which  will  invoke  the  module  from  time  to  time  to  check  for  transmissions 
coming  from  "outside"  which  would  otherwise  be  ignored.  For  example,  in  a 
configuration  where  layers  3  and  below  are  implemented  by  a  layer  3  interface 
module  which  talks  to  an  X.25  "chip",  an  "upward"  poll  event  would  be  installed 
at  layer  3  {to  check  for  transmissions  coming  in  via  the  chip),  as  well  as  a 
"downward"  poll  event  at  layer  U  (7.5)  which  causes  the  test  run  data  (script)  to 
be  input  to  the  system  when  appropriate. 

Following  state  initialization,  the  designated  test  file  is  searched  for  its  run 
data.  If  successful,  test  "script"  read  status  is  initialized;  otherwise  the  test 
performance  is  aborted. 

Assuming  that  all  the  "setup"  steps  have  been  successful,  the  actual 
execution  cycle  is  entered.  This  involves  searching  the  event  queue  for  events  yet 
to  be  processed,  and  processing  them.  The  phase  ends  when  no  events  remain  to 
be  processed,  or  a  "quit"  command  is  entered  by  the  operator.  Initially,  the  poll 
event  at  layer  7.5  causes  the  module  implementing  that  layer  to  "read"  the  test 
"script"  and  enter  appropriate  events  into  the  queue. 

4.1.5  Test  Post-mortems  Phase 

Following  the  successful  or  unsuccessful  performance  of  a  test,  its  results 
are  reported.  This  involves  printouts  of  both  completed  (fully  processed)  events, 
and  events  whose  processing  was  not  completed,  either  because  of  lack  of  time  or 
error  conditions  raised.  In  addition,  session  statistics  (primarily  resource  utilization) 
are  reported.  This  phase  also  serves  to  prepare  the  system  for  the  next  test 
performance. 

4.2  Test  Select  and  Test  (Processing)  Files 

In  order  to  perform  a  test,  two  "files"  are  needed;  the  test  file  itself  and  the 
test  select  file.  The  former  contains  (or  specifies  the  source  of)  the  test  "script" 
(run  data),  preceded  by  its  "standard"  (default)  configuration  parameters.  The  test 
select  file,  on  the  other  hand,  provides  parameter  values  which  supplement  or 
override  the  default  values  provided  in  the  test  file  itself.  The  following  sections 
describe  the  organization  of  and  the  syntaxes  used  in  these  two  files,  and  how 
they  are  used.  Both  files  are  sequential  formatted  (i.e.,  ASCII)  files  with  a 
maximum  record  length  of  eighty  (80)  characters,  of  which  only  the  first  72  are 
interpreted,  columns  73-80  being  reserved  for  sequencing  and  similar  purposes. 
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4.2.1  Test  (processing)  File  Organization 

The  test  file  itself  is  divided  into  two  parts:  its  default  parameter  section  and 
its  run  data.  The  parameter  section  is  headed  by  a  record  of  the  form: 

columns  1-16:  $TEST_PARAMETERS 
columns  17-32:  version  identification 
columns  33-72:  (not  used) 

The  version  identification  permits  several  different  sets  of  default  parameters 
for  a  given  test  to  be  "stacked"  on  a  single  file  for  convenience;  see  4.2.6. 1 
("TEST  =  "  parameter)  regarding  specific  version  selection. 

The  body  of  the  test  parameter  selection  uses  test  select  syntax  (4.2.3)  to 
supply  the  default  configuration  parameters  for  the  test.  While  this  same  syntax  is 
also  used  in  the  test  select  file  (4.2.2),  certain  parameters  and  forms  are  applicable 
only  in  the  test  file  itself;  these  are  described  in  4.2.5  below.  The  "script"  portion 
of  the  test  file  is  headed  by  a  record  of  the  form: 

columns  1-16:  $TEST_RUN_DATA  (left  justified) 
columns  17-32:  version  identification 
columns  33-72:  (not  used) 

As  in  the  parameter  portion,  the  version  identification  permits  stacking  of 
multiple  scripts  on  a  single  file;  see  4.2.6. 1  for  version  selection  methods.  The 
body  of  the  script  uses  test  processing  syntax  (4.2.7). 

The  script  consists  of  a  series  of  processing  commands  which  initiate, 
control,  and  terminate  the  performance  of  a  test.  As  presently  implemented,  only 
the  "/QUEUE"  (insert  an  event,  including  data  if  any,  into  the  event  queue), 
"/NOTE"  (provide  information  to  operator),  and  "/END"  commands  are  handled, 
although  much  of  the  design  and  infrastructure  implementation  have  been  done  to 
handle  conditional  and  iterative  processing,  as  well  as  handling  commands  and 
data  from  external  devices. 

4.2.2  Test  Select  Organization 

To  select  a  test,  the  operator  may  either  use  a  previously  prepared  test 
select  file  or  enter  the  necessary  test  select  parameters  on  line.  If  the  test  select 
parameters  are  "on  file",  they  must  be  headed  by  a  record  of  the  form: 

columns  1-16:  $TEST_SELECT  (left  justified) 
columns  17-32:  version  identification 
columns  33-72:  (not  used) 
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As  in  the  test  file,  the  version  identification  can  be  used  to  distinguish  between 
different  test  select  "decks”  stacked  on  the  same  file.  The  operator  chooses  a 
specific  version  by  including  its  identification  with  the  file  description  entered  in 
response  to  the  test  selection  request;  see  4.2. 6.1  for  the  form  used.  Regardless 
of  whether  the  test  selection  "file"  is  "canned"  or  entered  on  line,  its  body  follows 
the  test  select  syntax  described  in  4.2.3  below.  Certain  parameters  and  forms, 
however,  are  applicable  only  to  test  select  files;  these  are  described  in  section 
4.2.6. 

4.2.3  Test  Select  Syntax 

In  general,  the  body  of  a  test  select  file  (or  the  parameter  portion  of  a  test 
file)  consists  of  a  list  of  parameters  separated  by  commas  (or  one  or  more  blanks) 
and  terminated  by  a  dollar  sign.  The  list  may  occupy  one  or  more  records  (lines); 
the  line-to-line  boundary  has  the  effect  of  a  blank.  These  parameters  may  be 
parenthesized  by  groups,  either  for  readability  purposes  or  localization  control  (see 

4.2.4  below). 

To  aid  in  the  description  of  the  syntax,  especially  at  the  low  level,  certain 
metasyntactic  conventions  have  been  adopted  in  both  this  section  and  those 
following.  These  conventions  are; 

Uppercase  letters,  digits,  and  punctuation  generally  (except  for  square 
brackets  and  ellipses)  represent  themselves;  i.e.,  they  are  "fixed" 
representations  to  be  used  exactly  as  written. 

Lowercase  letters  represent  "variable"  (generally  alphanumeric) 
syntactic  entities  to  be  "filled  in",  or  whose  representation  is 
elsewhere  described  (i.e.,  "non-terminals"). 

Square  brackets  (U)  set  off  optionally  omitted  parts  of  the  syntactic 
item  in  question.  -  An  ellipsis  (...)  following  an  optional 
(square-bracketed)  part  indicates  zero  or  more  repetitions  of  that  part. 

blanks  are  used  freely  to  enhance  readability. 

For  example,  the  form  described  by: 

PARM  =  val[,val]... 

covers  all  of  the  following  instances; 

PARM  =  A 
PARM  =  R,  S 
PARM  =  U,V,X,Y,Z 
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but  does  not  cover  either  of  the  following: 

VAL  =  A  (must  be  "PARM") 

PARM  (nonoptional  "=val"  missing) 

4.2.3. 1  High-level  Syntax 

The  overall  form  of  a  test  select  "deck"  is: 
paramlist  $ 

where  the  form  of  "paramlist"  is: 

[parameter!, parameter]...] 

i.e.,  a  possibly  empty  list  of  parameters  as  noted  above.  Note  that  the  empty  case 
is  valid  only  for  the  test  parameter  portion  of  a  test  file;  a  test  select  file  must 
contain  test  file  identification,  at  least.  These  definitions  are  given  here  for 
recursive  use  in  defining  parenthesized  parameter  values  (see  4.2. 3. 4). 

4. 2. 3. 2  Parameter  Format 

The  form  of  a  single  parameter  is: 

[paramname  =  ]  paramvalue 

The  "keyworded"  form  (where  "paramname  ="  is  present)  is  normally  used  where 
a  specific  parameter  value  is  to  be  supplied.  For  example,  assuming  prior 
localization  to  layer  5: 

CT1T  =  45 

sets  the  T.62  (layer  5)  T1  (inactivity)  timeout  period  to  45  seconds. 

The  "positional"  form  (where  the  name  is  omitted)  is  chiefly  used  in  those 
cases  where  the  parameter  concerned  can  have  only  two  possible  values  (e.g., 
"on"  or  "off"),  and  the  value  can  consist  of  the  parameter  name  itself,  possibly 
preceded  by  a  confirming  or  denying  sign.  For  example,  in  the  same  context  as 
above: 

QULL 

causes  the  layer  5  module  to  produce  "long"  (3-octet)  length  indicators  regardless 
of  the  length  to  be  represented. 
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Certain  specific  parameters  are  actually  positional;  i.e.,  their  effect  depends 
on  their  position  in  the  test  select  deck  as  a  whole.  For  example,  in  the  test  select 
file,  the  test  identification  parameter  is  usually  keyed  with  the  parameter  name 
"TEST",  but  in  the  absence  of  such  a  parameter,  the  first  parameter  in  the  file,  if 
not  keyworded,  is  assumed  to  be  the  test  identification  parameter. 

4. 2. 3. 3  Keyword  (paramname)  Format 

A  keyword  must  consist  of  a  letter  followed  by  0-7  letters  or  digits.  Within 
a  keyword,  case  is  not  significant;  all  letters  are  handled  as  if  in  uppercase;  for 
example,  the  keywords  "key",  "KEY",  and  "Key"  are  equivalent,  all  being 
represented  by  the  capitalized  form  "KEY". 

Keywords  supply  the  "names"  of  parameters,  which  can  generally  be  divided 
into  three  classes:  global  (e.g.,  test  identification),  local  (e.g.,  CT1T  above),  and 
"localizing"  parameters,  which  restrict  the  effect  of  following  local  parameters  to 
specific  sides,  ends,  and  layers. 

4.2. 3. 4  Parameter  value  (paramvalue)  format. 

Parameter  values  may  assume  any  of  seven  forms: 

[sign]  anvalue 
'string' 

"string" 

(paramlist) 

# 

& 

[]  (i.e.,  null) 

In  the  first  form  above,  "anvalue"  is  a  string  containing  digits,  letters,  underscores, 
or  a  mixture  of  them;  its  maximum  length  is  72  characters.  As  in  keywords,  case 
is  not  significant;  all  letters  are  treated  as  if  in  upper  case.  If  only  digits  are 
involved,  it  is  interpreted  as  a  decimal  value;  otherwise  its  interpretation  is 
dependent  on  the  specific  parameter  concerned. 

The  optional  "sign"  may  be  either  a  plus  (  +  )  or  a  minus(-).  The  latter  has  the 
effect  of  negating  the  value  "anvalue",  either  arithmetically  (if  the  value  is  numeric) 
or  logically.  For  example,  in  the  context  of  the  second  example  in  4. 2. 3. 2  above: 

-QULL 

has  the  effect  of  "turning  off"  the  "long  length  indicator"  force  implied  by  the 
unsigned  form  of  the  value.  A  plus  ( + )  sign,  on  the  other  hand,  just  "affirms"  the 
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"positive"  sense  of  the  value;  its  use  is  equivalent  to  the  omission  of  the  sign 
entirely. 


The  delimited  string  forms  (second  and  third  in  the  list  above),  may  contain 
any  printable  ASCII  characters,  with  the  restriction  that  an  occurrence  of  the 
delimiting  character  itself  within  "string"  must  be  represented  by  a  pair  of  the 
character  with  no  other  characters  intervening. 

For  example,  the  value: 

That's  all  folks 

could  be  represented  by  either: 

'That"s  all,  folks' 
or: 

"That's  all,  folks" 

In  this  form,  case  is  significant;  "a"  is  not  equivalent  to  "A". 

The  delimited  form  is  generally  used  when  the  value  must  contain  blanks  or 
other  special  characters.  For  example,  this  form  is  required  in  the  test 
identification  parameter  on  the  test  select  file,  where  colons,  periods,  etc.  are 
needed  to  satisfy  file  description  directory  syntax,  as  well  as  to  set  off  imbedded 
version  identification. 

The  fourth  (parenthesized)  form  is  used  to  group  related  parameters  for 
documentation  purposes,  and  to  limit  localization  effects  (see  4.2.4  below).  If  the 
value  of  a  keyworded  parameter  is  of  this  form,  and  the  first  parameter  in  the 
parenthesized  list  is  not  keyworded,  the  group  keyword  is  assumed  to  apply  to  that 
first  grouped  parameter.  For  example: 

LYR  =  (5,QULL) 

is  equivalent  to: 

(LYR  =  5,QULL) 

Other  uses  of  group  keywords  have  essentially  no  effect  except  for  documentation 
purposes  and  certain  uses  in  the  test  parameter  section  of  the  test  file  (see  section 
4.2.5). 
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The  last  three  forms  ("*",  "&",  and  null)  are  applicable  only  to  the  test 
select  file;  their  use  is  described  in  section  4. 2. 6. 2.  Generally,  they  specify  the 
choice  of  either  the  last  used  (repeat)  or  standard  (default)  value  for  the  parameter 
in  question. 

4. 2. 3. 5  Use  of  blanks. 

Generally,  blanks  may  be  used  freely  adjacent  to  other  "breaks"  to  enhance 
the  readability  of  the  selection  list.  One  or  more  blanks  may  also  be  used  to 
separate  parameters  themselves;  when  so  used,  they  have  the  effect  of  a  comma. 
However,  blanks  may  not  be  embedded  in  keywords  or  in  the  "anvalue"  portion  of 
the  first  parameter  value  form  (4. 2. 3. 4  above),  although  they  may  be  used 
between  the  sign  and  the  value  proper.  This  restriction  further  implies  that 
keywords  and  "anvalues"  may  not  be  split  between  lines.  To  limit  the  possible 
lexical  "states"  at  the  end  of  a  line,  splitting  of  values  in  the  delimited  string  form 
is  also  prohibited. 

Blanks  used  adjacent  to  "breaks"  are  not  significant;  if  a  set  of  blanks  is 
used  as  a  break,  its  only  sigr  ‘*icance  is  the  separation  function  itself.  However, 
blanks  imbedded  within  delimited  string  values  form  a  significant  part  of  that  value. 


4.2.4  "Localizing"  Parameters 

As  has  been  noted  elsewhere,  the  "core"  of  the  test  execution  subsystem 
consists  of  sets  of  modules  for  each  OS!  layer  plus  translation  half-layers  between. 
The  set  for  a  specific  layer  or  half-layer  can  operate  differently  for  each  side  and 
end  combination  involved  in  the  test  as  configured.  To  permit  this,  it  is  necessary 
to  restrict  the  effect  of  "local"  parameters  to  the  specific  side/end/layer 
combinations  used,  as  well  as  to  limit  the  scope  of  layer-specific  parameter  names 
to  avoid  conflicts.  The  "localizing"  parameters  perform  this  restriction  function  by 
selecting  the  specific  sides,  ends,  and  layers  affected  by  following  layer-specific 
parameters. 

Test  select  processing  (for  both  the  test  select  file  and  the  parameter  portion 
of  the  test  file)  not  only  stores  the  names  and  values  of  the  parameters  specified, 
but  also  notes  which  side/end/layer  combinations  are  affected  by  them.  Initially  (at 
the  beginning  o>  the  deck),  all  side,  end,  and  layer  selections  are  "off"  (for 
processing  context-independent  "global"  parameters);  to  make  "local"  parameters 
effective  at  least  one  side/end/layer  combination  must  be  "turned  on".  This 
functic  t  is  performed  by  the  "SID",  "END",  and  "LYR"  parameters  acting 
independently. 

The  effect  of  one  of  these  "localizing"  parameters  persists  until  "switched" 
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off  or  to  another  combination;  its  effect  applies  also  to  any  parenthesized 
parameter  groups  "nested"  following  it  at  the  same  level.  However,  the  effect  of  a 
localizing  parameter  within  a  parenthesized  group  "dies"  at  the  end  of  the  group; 
for  example,  in  the  following  parameter  list  fragment: 

...,(LYR  =  5,QULL),PABC,... 

the  effect  of  QULL  is  localized  to  layer  5,  but  localization  of  PABC  is  dependent  on 
that  in  effect  prior  to  the  parenthesized  group. 

4.2.4. 1  Side  Selection  Parameters. 


The  form  of  a  side  selection  parameter  is: 

SID  =  sidv 

where  "sidv"  chooses  the  effective  side(s)  for  subsequent  local  parameters  as 
follows: 


Side(s)  to  be  selected 


Test  (UUT)  side 
Control  emulation  side 
Both  sides 

Neither  side  (turnoff) 


Alternative  "sidv”  values 


TEST,  UUT,  U,  or  1 
CTRL,  EMUL,  E,  C,  or  2 
BOTH  or  B 

0  (or  none  of  the  above) 


4. 2.4. 2  End  selection  parameters. 

The  form  of  an  end  selection  parameter  is: 
END  =  endv 


where  "endv"  chooses  the  effective  end  for  subsequent  local  parameters  as 
follows: 


End (s)  to  be  selected 


Tester  (near)  end 
UUT  (far)  end 
Both  ends 

Neither  end  (turnoff) 


Alternative  "endv"  values 


NEAR,  TEST,  N,  T,  or  1 
UUT,  FAR,  U,  T,  or  2 
BOTH  or  B 

0  (or  none  of  the  above) 
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4. 2. 4. 3  Layer  Selection  Parameters. 

This  parameter  may  be  used  to  select  either  a  single  layer,  no  layer  (turnoff), 
or  a  range  of  contiguous  layers.  The  form  of  a  single  layer  selection  is: 

LYR  =  lyrv 

where  "lyrv"  indicates  the  layer  to  be  selected. 

The  form  of  the  layer  range  selection  is: 

LYR  =  lyrva_lyrvb 

where  "lyrva"  and  "lyrvb"  indicate  the  (inclusive)  ends  of  the  range  specified.  The 
various  layers  and  half-layers  are  represented  as  follows: 


Layer 

Description 

Alternative  "lyrv"  values 

0.5 

physical  near <-> far 

A,  H,  or  OH 

connection 

1.0 

physical  layer 

PHY  or  1 

1.5 

physical  <->  link 

B  or  1H 

2.0 

link  layer 

LNK  or  2 

2.5 

link  <->  network 

C  or  2H 

3.0 

network  layer 

NTW  or  3 

3.5 

network  <  -  >  transport 

D  or  3H 

4.0 

transport  layer 

TRN  or  4 

4.5 

transport  <  -  >  session 

E  or  4H 

5.0 

session  layer 

SSN  or  5 

5.5 

session  <  -  >  presentation 

F  or  5H 

6.0 

presentation  layer 

PRS  or  6 

6.5 

presentation  <  -  >  application 

G  or  6H 

7.0 

application  layer 

APP  or  7 

7.5 

user <-> application  interface 

U  or  7H 

(none) 

(turnoff) 

0  (or  none  of  above) 

For  example:  LYR  =  A_3  selects  layers  0.5  through  3.0  inclusive. 

4.2. 4. 4  Layer  configuration  parameters. 

While  this  particular  parameter  is  strictly  a  "local"  rather  than  a  "localizing" 
parameter,  it  is  described  in  this  section  because  its  semantics  is  shared  by  all 
layers,  as  opposed  to  the  majority  of  local  parameters  whose  names  and  functions 
are  peculiar  to  specific  layers.  The  function  of  this  parameter  is  to  described  what 


50 


layers  are  "present"  (on  a  given  side  and  end)  and  how  they  are  "accessible"  to  the 
event  queue  in  the  given  test  performance.  A  given  configuration  parameter  may 
specify,  for  example,  that  layer  3  is  "accessible"  from  higher  layers  (3.5  and 
above)  but  not  from  below  (2.5  and  lower),  because  the  latter  layers  are  "buried" 
in  an  X.25  "chip".  The  semantics  of  this  particular  parameter  was  made  common 
to  all  layers  in  order  to  facilitate  consistency  checks  between  the  configurations  in 
adjacent  layers. 


The  form  of  the  layer  configuration  parameter  is: 

CONFIG  =cfgv  where  "cfgv"  chooses  the  appropriate  configuration  option: 


Layer  configuration 


Protocol  or  translator, 
fully  accessible 
Interface  accessible  from 
higher  layers  only 
Interface  accessible  from 
lower  layers  only 
Inaccessible  layer  (buried 
in  hardware) 

Not  present  (turnoff) 

4.2.5  Parameters  Specific  to  Test  File 


Alternative  "cfgv"  values 

PROTOCOL,  TRANSLAT,  PRTCL, 
TRNSLT,  PR,  TR,  P  or  T 
UINTF,  Ul,  HINTF  or  HI 

LINTF,  LI,  BINTF  or  Bl 

MINTF  or  Ml 

(negation  of  any  of  above) 


Certain  parameters  and  forms  are  applicable  only  to  the  test  parameter 
portion  of  the  test  file.  These  parameters  provide  a  means  for  the  test  writer  to 
regulate  the  use  of  the  test  select  file  to  supplement  and/or  override  "standard" 
test  parameters. 


4.2.5. 1  Override  Prevention. 


By  the  use  of  the  FIXED  parameter  keyword,  the  test  file  can  prevent  the 
test  select  file  from  overriding  specified  parameter  values  in  the  test  file.  This 
keyword  is  used  as  follows: 

FIXED  =  (paramlist) 

This  usage  causes  the  diagnosis  of  an  error  (INVALID  SELECT;  FIXED  BY 
TEST)  if  the  test  select  file  attempts  to  supply  a  value  for  any  of  the  parameters  in 
the  parenthesized  "paramlist"  above.  The  error  will  be  diagnosed  separately  for 
each  "fixed"  parameter  and  each  side/end/layer  combination  "covered". 
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The  FIXED  parameter  does  not  affect  the  "localizing"  parameters  (4.2.4 
above),  but  works  in  parallel  with  them.  To  illustrate  this,  in  the  following 
fragment: 

..., FIXED  =  ((LYR  =  5,-QULL),PXYZ  =  1 ),... 

overrides  of  the  QULL  parameter  are  prohibited  for  layer  5  only,  but  the 
combinations  for  which  PXYZ  overrides  are  prevented  depends  on  the  localization 
in  effect  (if  any)  prior  to  the  FIXED  parameter  in  the  test  parameter  list. 
Parenthesized  list  it  keys,  including  any  further  lists  nested  within  it,  unless 
"switched"  by  a  REQUIRED  or  OPTIONAL  parameter  in  the  list. 

4. 2. 5. 2  Requirement  for  Supply  of  Value 

The  REQUIRED  parameter  demands  that  the  test  select  file  supply  values  for 
specific  parameters  in  the  same  way  that  the  FIXED  parameter  prohibits  it.  It  is 
used  similarly: 

REQUIRED  =  (paramlist) 

An  error  will  be  diagnosed  (REQUIRED  USER  SELECTION  ABSENT)  if  the  test 
select  file  does  rot  supply  a  value  for  each  of  the  parenthesized  parameters. 
Similarly  to  the  FIXED  parameter,  values  must  be  supplied  (separately  or  together) 
for  each  side/end/layer  combination  in  effect  (within  the  test  file)  for  the  parameter 
in  question.  The  parameters  within  the  REQUIRED  parenthesized  list  are  normally 
written  as  keyworded  with  null  values;  for  example: 

...,CONFIG  = ,... 

to  emphasize  that  values  must  be  supplied.  This  is  an  exception  to  the  use  of  this 
form  only  in  test  select  files. 

4.2. 5. 3  Optional  Override  Restoration. 

The  OPTIONAL  parameter  is  used  to  "turn  off"  the  effect  of  either  the  FIXED 
or  REQUIRED  parameter: 

OPTIONAL  =  (paramlist) 

Its  use  restores  the  "normal"  mode  of  operation,  in  which  either  the  test 
parameters  or  the  test  select  file  may  supply  the  value  for  a  given  parameter,  the 
test  select  value  being  used  if  both  do.  The  persistence  of  its  effect  is  similar  to 
that  of  the  FIXED  and  REQUIRED  parameters,  as  is  its  interaction  with  localizing 
parameters. 
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4.2.6  Parameters  Specific  to  the  Test  Select  File 

Certain  parameters  and  value  forms  have  meaning  only  within  the  test  select 
file.  These  are  the  test  identification  parameter  and  the  indirect  value  references. 

4.2.6. 1  Test  Identification  Parameter 

This  parameter  is  used  to  specify  the  test  file  to  be  used.  Its  form  is  one  of 
the  following: 

[TEST  =  ]'[filedesc][,U  =  unit][,V  =  version]' 

[TEST  =  ]"[filedesc][,U  =  unit][,V  =  version]" 

[TEST  =  ]* 

[TEST  =  ]& 

The  keyword  TEST  may  be  omitted  only  if  the  parameter  is  the  first  in  the 
test  select  file;  in  this  case,  it  must  not  be  within  a  parenthesized  list.  The 
remaining  parts  are  used  to  identify  the  test  file  by  directory  information  (or  as  the 
last  test  performed),  supply  a  specific  unit  number  to  read  it,  and  to  select  a 
specific  version  of  it  if  required.  The  "filedesc"  part  must  be  the  first  within  the 
delimited  string,  but  the  "unit"  and  "version"  parts  may  be  in  either  order.  The 
handling  software  will  also  permit  (but  not  interpret)  other  comma-separated  parts 
(to  allow  for  future  enhancements)  anywhere  after  the  "filedesc"  part.  Trailing 
commentary  is  also  allowed,  indicated  by  a  preceding  exclamation  mark(l). 

4. 2. 6. 1.1  File  Descriptor 

The  file  description  part  is  normally  required,  but  may  be  omitted  if  the  unit 
part  (4. 2. 6. 1.2)  is  sufficient  to  identify  the  test  "file".  The  form  of  "filedesc"  must 
be  such  that  it  can  be  used  as  a  "filename"  specifier  in  a  Fortran  OPEN  statement 
preparatory  to  reading  the  test  file.  The  use  of  the  asterisk  [*)  or  ampersand  (&) 
forms  indicate  that  the  test  to  be  selected  is  the  one  just  performed.  The  asterisk 
specifies  that  the  test  is  to  use  parameter  values  as  last  performed  (except  for 
specific  values  in  the  test  select  file);  the  ampersand,  that  "standard"  parameter 
values  (as  specified  in  the  test  file  itself)  are  to  be  used. 

4.2. 6. 1.2  Unit  Specifier. 

The  unit  specifier  may  be  omitted  except  when  the  file  descriptor  is  absent, 
or  when  a  specific  unit  number  is  to  be  used  to  read  the  test  file.  Its  value  "unit" 
must  be  in  the  form  of  a  decimal  integer  suitable  for  use  as  a  Fortran  unit  number 
in  OPEN  and  READ  statements.  Omission  of  this  parameter  causes  a 
program-defined  default  unit  number  to  be  used  for  reading  the  test  file. 
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4.2. 6. 1.3  Version  Specifier 

This  specifier  is  used  to  identify  specific  versions  of  both  the  test  parameters 
and  the  test  run  data  parts  on  the  test  file.  Its  value  "version"  must  be  an 
alphanumeric  string  one  to  sixteen  characters  in  length.  Its  purpose  is  to  select 
one  of  several  different  test  parameter  or  run  data  "decks"  stacked  on  a  single  file. 
If  the  version  specifier  is  omitted  from  the  test  identification  parameter,  the  version 
portion  of  the  deck  header  (columns  17-32;  see  4.2.1)  is  ignored;  i.e.,  the  first 
version  found  will  be  selected. 

4. 2. 6. 1.4  Test  Select  File  Identification 

The  same  options  used  in  the  test  select  file  to  identify  the  test  file  may  be 
used  to  identify  by  the  operator  to  identify  the  test  select  file  when  requested  to 
do  so  by  the  validator,  although  with  adaptations  to  on-line  entry.  Specifically,  the 
explicit  form  of  test  select  file  identification  becomes: 

[filedesc][,U  =  unit][,V  =  version] 

where  the  keyword  and  the  string  delimiters  have  been  dropped.  For  this  usage, 
"filedesc"  identifies  the  test  select  file  rather  than  the  test  file;  the  uses  of  the 
"unit"  and  "version"  parameters,  however,  completely  parallel  those  in  test 
identification. 

4.2. 6.1. 5  NEW,  REPEAT,  and  DEFAULT  Parameters 

While  the  NEW,  REPEAT  and  DEFAULT  parameters  are  syntactically  separate 
from  the  test  identification  parameter,  their  function  is  essentially  inseparable  from 
it.  Their  form  is  as  unkeyworded  parameters: 

NEW 

REPEAT 

DEFAULT 

One  of  them  may  be  used  immediately  following  the  test  identification  parameter, 
i.e.  as  the  second  test  select  parameter;  the  test  identification  must  be  explicit. 
Their  use  is  to  "force"  the  read  of  the  test  file,  or  to  permit  inclusion  of  the  explicit 
test  file  identification  even  if  the  last  performed  test,  or  its  "standard"  version,  is 
to  be  re-run. 

The  NEW  parameter  specifically  forces  the  identified  test  to  be  read,  even 
though  the  same  test  was  just  performed.  The  REPEAT  parameter  permits  the 
inclusion  of  the  test  identification  for  repeating  the  test  just  run  (identifications 
must  match)  for  logging  purposes.  For  example,  if  the  test  just  run  was  identified 
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as  A:TESTABC.TST,  then: 

TEST  =  'A:TESTABC.TST',  REPEAT 
is  equivalent  to  (and  better  for  logging  purposes  than): 
TEST  =  * 


The  DEFAULT  parameter  permits  similar  inclusion  of  the  test  identification  when 
the  "standard"  test  is  to  be  repeated. 

4.2. 6. 2  Indirect  Value  References 

In  the  test  select  file,  parameter  values  may  be  indirect  references  to  those 
used  as  "standard"  for  the  test  involved  or  to  the  values  used  in  the  test  just 
performed.  The  form  of  such  an  indirect  reference  is  (from  4. 2. 3. 3  above)  one  of: 

# 

& 

[]  (null) 

The  asterisk  (*)  indicates  that  the  last  used  value  for  the  parameter  in  question  is 
to  be  "picked  up";  it  is  applicable  only  if  the  same  test  is  to  be  performed  as  the 
same  as  was  last  done.  The  ampersand  (&)  specifies  that  the  "standard"  value 
(from  the  test  parameters)  is  to  be  used.  Finally,  the  null  form  "goes  with  the 
test";  it  has  the  effect  of  if  the  test  is  a  repeat,  the  effect  of  "&"  if  "default", 
and  is  ignored  if  the  test  is  "new".  For  example,  in  the  following  fragments:) 

TEST  =  *,...,  PARA  =  &,  PARB  = ,  PARC  =  *,... 

PARA  assumes  its  "standard"  value,  but  both  PARB  and  PARC  assume  the  values 
used  in  the  last  performance  of  the  test,  PARC  explicitly,  but  PARB  because  the 
test  itself  is  a  repeat.  Because  of  localization,  a  single  "*",  for  example,  may 
cause  several  different  values  to  be  picked  up.  For  example,  if  the  localization  of  a 
single  parameter  for  which  is  specified  covers  several  layer/side/end 
combinations,  a  different  value  may  be  picked  up  for  each  combination. 

4.2.7  Test  Processing  (run  data)  Syntax 

The  run  data  (script)  portion  of  the  test  file  contains  the  test  processing 
commands  which  initiate,  control,  and  supply  data  during  test  execution. 

Generally,  the  script  consists  of  a  series  of  commands,  each  of  which  comprises 
one  or  more  records.  The  script  is  terminated  by  a  "sentinel"  record  which  has  a 
dollar  sign  ($)  in  column  1.  The  first  (header)  record  of  each  command  has  the 
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following  format: 

column  1  :  / 

columns  2-  8:  command 

columns  9-72:  dependent  on  specific  command,  but  normally 
divided  into  eight  8-column  fields. 

The  remaining  records  of  the  command  have  a  blank  in  column  1,  but  their  format 
is  otherwise  dependent  on  the  specific  command. 

With  the  exception  of  the  "/NOTE"  command,  ail  the  commands  so  far 
implemented  do  not  depend  on  the  column  1  convention  above  to  "complete"  their 
definition;  they  "know"  when  they're  "finished".  As  a  result,  processing  these 
commands  which  inadvertently  have  too  few  or  too  many  continuation  records  will 
result  in  appropriate  diagnostics.  It  is  felt  that  this  is  a  worthwhile  "fail-soft" 
practice  to  continue.  While  provision  has  been  made,  and  the  infrastructure  built 
for,  many  more  commands  involving  conditional  execution,  iteration  of  script 
portions,  and  transmission  of  data  or  processing  commands  from  remote  devices, 
only  the  /QUEUE  (insert  event  into  the  queue),  /NOTE  (provide  information  and 
"breakpoint"  to  operator),  and  /END  (terminate  test  processing)  commands  have 
been  implemented  at  the  present  time. 

4.2.7. 1  General  Notes  on  Script  Processing. 

All  script  processing  is  done  during  the  test  execution  phase.  When  the 
user-application  layer  module  is  invoked  by  the  poll  event  provided  for  that 
purpose,  it  in  turn  invokes  the  test  processing  module  which  "reads"  the  script; 
this  module  then  processes  one  or  more  commands;  any  events  resulting  are  then 
processed  by  the  interface  module.  This  mechanism  is  first  used  to  insert  "seed" 
events  into  the  queue,  and  later  to  supply  further  "external"  control  and  data. 

cina!!y,  the  /END  . . u.'.l  ":ermiP2te'"  c  s-'-ipt  (but  not  the  test),  and  allows 

the  test  to  work  itself  out. 

4. 2. 7. 2  Event  Insertion 

The  /QUEUE  command  is  used  to  build  and  insert  an  event  (with  or  without 
data)  into  the  event  queue.  While  this  event  is  normally  "aimed"  at  the 
user-application  layer  interface  (layer  7.5)  at  the  tester  (near)  end,  the  /QUEUE 
command  may  build  events  targeted  toward  any  layer/side/end  combination.  The 
form  of  the  /QUEUE  command's  header  line  is: 
columns  1-  8:  /QUEUE 
columns  9-16:  [procoptl 
columns  17-24:  [evcode] 
columns  25-72:  [fldspec]...[dataspec] 
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Each  field  specification  "fldspec"  occupies  a  separate  eight-column  field. 

The  data  specification  "dataspec",  if  used,  occupies  one  or  more  eight-column 
fields.  These  specifications  need  not  be  left-justified  in  their  fields,  and  trailing 
blanks  in  the  fields  are  ignored,  except  in  the  "middle"  of  the  "dataspec".  Except 
for  the  "dataspec",  which  must  be  last  if  used,  the  specifications  may  be  in  any 
order. 

4. 2. 7. 2.1  Processing  Option 

The  processing  option  field  "procopt"  specifies  whether  the  test  processor 
will  return  control  to  the  event  queue  (via  the  user-application  layer  interface 
module)  after  building  and  inserting  the  event.  The  form  of  "procopt"  is  one  of: 

PROCESS 

HOLD 

The  first  (PROCESS)  form  causes  immediate  return  of  control  after  event 
insertion;  the  second  (HOLD)  allows  the  test  processing  module  to  continue 
reading  the  script.  If  the  "procopt"  field  is  blank,  PROCESS  is  assumed. 

4. 2. 7. 2. 2  Event  Code 

This  field  specifies  the  event  code  to  be  used  in  the  event.  Its  form  is  as 
follows: 

[eg  +  ]evc 

in  which  the  use  of  the  optional  event  group  indicator  "eg"  permits  specification  of 
the  code  relative  to  a  group  "base";  the  omission  permits  specifying  the  code  in 
absolute  terms.  If  the  optional  "eg"  is  used,  it  must  be  a  two-character  event 
group  indicator  occurring  in  the  following  list: 


Indicator 

Description 

Implied  layer 

OH 

layer  0.5  local 

0.5 

10 

layer  1.0<->0.5 

1.0 

11 

layer  1 .0  peer  &  local 

1.0 

12 

layer  1 ,0<->  1 .5 

1.0 

1H 

layer  1 .5  local 

1.5 

76 

layer  7.0<->6.5 

7.0 

77 

layer  7.0  peer  &  local 

7.0 

7U 

layer  7.0<->7.5(U) 

7.0 

7H 

layer  7.5(U)  local 

7.5 

*(see  4.2. 7. 2. 3.1.) 
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The  event  code  portion  "eve"  is  interpreted  as  a  decimal  integer.  The  event 
code  to  be  used  in  the  event  is  calculated  by  adding  the  value  of  "eve"  to  that  for 
the  group  base  (if  any)  or  to  zero  if  no  group  is  specified.  The  group  base  value  is 
the  event  code  for  the  "zeroth"  event  in  the  group,  i.e.,  one  less  than  the  lowest 
event  code  of  the  group.  If  columns  17-24  are  blank,  the  event  code  of  the 
user-application  layer  poll  event  is  used. 

4. 2. 7. 2. 3  Other  Event  Field  "fldspec"  Specifications 

The  field  specifications  "fldspec"  are  used  to  populate  the  remaining 
"non-pointer"  fields  of  the  event.  Each  "fldspec"  is  one  of: 


Isespec 

dtpspec 

auxspec 

sscspec 

clkspec 


(layer/side/end) 

(direction/target/priority) 

(auxiliary) 

(state/substate  change) 
(clock  time) 


A  single  /QUEUE  command  can  contain  no  more  than  one  of  each  kind  of 
"fldspec". 


4. 2. 7. 2. 3.1  Layer,  Side,  and  End. 

The  form  of  "Isespec"  is  either  of; 


L  =  Ise 
L  =  ? 


where  "I",  "s",  and  "e"  are  separate  one-character  indicators,  either  alphanumerics 
indicating  specific  layers,  sides,  and  ends,  or  asterisks  (*)  which  call  for  the  default 
values. 

Valid  layer  indicators  are  "A","1","B",...,"G","7",  or  "U",  where  the  digits 
represent  "full"  layers  and  the  letters  the  translating  "half-layers".  The  default  (if 
"I"  is  or  "Isespec”  is  omitted)  is  the  implied  layer  for  the  event  code  specified 
(see  4. 2. 7. 2. 2.  table). 

Valid  side  indicators  are  "U"  (UUT,  tester)  or  "C"  (control  emulation).  The 
default  is  "U". 

Valid  end  indicators  are  "N"  (near,  tester)  or  "F"  (far,  UUT).  The  default  is 

"N". 


For  example,  the  specification: 
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L  =  5C#  indicates  the  target  to  be  layer  5  on  the  control  emulation  side  at  the 
"near"  end  (the  last  by  default). 

The  second  form  of  "Isespec"  (with  the  question  mark)  causes  the  operator 
to  be  prompted  to  enter  the  layer,  side,  and  end  in  the  "Ise"  form  (without  the 
keying"L  =  "). 

4. 2. 7. 2. 3. 2  Direction,  Target,  and  Priority  ("dtpspec"). 

The  form  of  "dtpspec"  is  either  of: 

H  =dtp 
H  =  ? 


where  "d",  "t",  and  "p"  are  separate  one-character  indicators  of  the  event 
direction,  target  module  class,  and  handling  priority  respectively.  Functionally, 
these  indicators  may  be  in  any  order;  the  indicator  value  itself  indicates  which  of 
the  three  fields  it  specifies.  If  no  value  specifying  a  field  is  used,  the  field  assumes 
its  default  value. 

Valid  direction  indicators  are  "U"  (upward)  or  "D"  (downward);  downward  is 
the  default  direction.  Valid  target  classes  are  "K"  (comparator  or  traffic  cop 
module),  "P"  (protocol  or  translator  module),  or  "I"  (interface  module);  default  is 
"K".  Valid  priority  indicators  are  "X"  (express),  "N"  (normal),  or  "T"  (deferred 
timeout);  "N"  is  the  default. 

For  example,  the  handling  specification: 


H  =TP 


specifies  a  downward  direction  (by  default),  a  protocol  module  target,  and  deferred 
timeout  priority. 

The  second  form  of  "dtpspec"  causes  the  operator  to  be  prompted  for  the 
"dtp"  information,  similarly  to  the  corresponding  "Isespec"  form. 

4. 2. 7. 2. 3. 3  Auxiliary  Field 

The  form  of  the  auxiliary  field  specificat.on  "auxspec"  is  either  of: 

A  =  hh 
A  =  ? 

where  "hh"  is  one  or  two  hexadecimal  digits  whose  value  will  be  used  to  populate 
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the  auxiliary  field  of  the  event.  This  field  defaults  (if  no  "auxspec"  is  used)  to  zero. 
The  second  form  causes  the  operator  to  be  prompted  for  this  value  as  in  the 
explicit  form. 

4. 2. 7. 2. 3. 4  States  and  Substate  Change. 

The  form  of  "sscspec"  is  either  of: 

[S  =  ]nn[<oo[/cc]] 

S  =  ? 


with  the  constraint  in  the  first  form  that  not  both  the  keying  HS  =  "  and  the  "less 
than"  (<)  part  be  omitted.  In  the  first  form,  "nn",  "oo",  and  "cc"  are  each  one  or 
two  hexadecimal  digits,  whose  values  are  to  be  used  to  populate  the  new  state, 
old  state,  and  substate  change  fields  of  the  event  respectively.  In  the  second  form, 
the  operator  is  prompted  for  this  information,  to  be  supplied  as  in  the  first  form, 
omitting  the  keying  "S  =  ".  Omitted  fields  default  to  zero. 

4. 2. 7. 2. 3. 5  Clock  Time  Specification 

The  form  of  the  clock  time  specification  "clkspec"  is  either  of: 

@[  +  ]hhmmss 
<§>(  =  ]? 

In  the  first  form,  the  use  of  the  plus  (  +  )  indicates  that  the  value  of  the  following 
"hhmmss"  is  to  be  added  to  the  current  clock  time  (i.e.,  is  incremental);  the 
omission  of  the  plus  indicates  that  "hhmmss"  is  to  be  interpreted  absolutely, 
"hhmmss"  must  be  a  string  of  digits  representing  hours,  minutes,  and  seconds.  If 
less  than  six  digits,  it  is,  in  effect,  right  justified  and  padded  on  the  left  with 
zeroes.  For  example: 

@  +  230 

indicates  that  the  clock  time  to  be  used  in  the  event  is  the  current  clock  time  plus 
two  and  a  half  minutes. 

The  second  form  calls  for  operator  input  of  the  absolute  or  incremental  time 
to  be  used  in  the  event;  the  form  used  should  follow  the  first  form  above  (less  the 
keying  "@"). 

4. 2. 7. 2. 4  Data  Specification 

The  data  specification  on  a  /QUEUE  header  may  completely  contain  the  data, 
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indicate  that  the  data  is  on  following  continuation  records,  or  indicate  that  the 
operator  is  to  supply  it.  The  form  of  the  data  specification  is  one  of: 

D  =  'string' 

D  =  "string" 

D  =  & 

D  =  ? 

In  the  first  two  forms,  the  data  for  the  event  consists  of  the  delimited  string. 
Within  the  string,  the  usual  rules  are  followed  for  representing  the  delimiter 
character  itself:  it  must  be  doubled  without  intervening  characters. 

The  third  form  indicates  that  the  data  itself  are  on  one  or  more  continuation 
records  following,  while  tho  last  form  causes  the  operator  to  be  prompted  to 
supply  the  data.  If  the  /QUEUE  header  does  not  contain  a  data  soecification,  the 
event  carries  no  data  package. 

In  the  following  paragraphs,  the  expected  form  of  the  data,  either  on 
continuation  records  or  as  operator  input,  will  be  detailed.  Alternate  methods 
capable  of  supplying  "non-ASCII"  data  will  be  described  for  both  modes  of  input. 
The  approach  will  be  to  describe  simple  "ASCII"  continuation  and  note  the 
differences  if  "non-ASCII"  data  and/or  operator  input  are  involved. 

4. 2. 7. 2. 4.1  ASCII  Data  Continuation 

This  form  may  be  used  if  the  data  consists  entirely  of  printable  ASCII 
characters.  It  may  also  be  used  for  those  records  containing  such  data  in 
multirecord  data  "packages". 

For  a  /QUEUE  command  in  which  the  "dataspec"  is  "D  =  &",  the  data  which 
are  to  form  the  event  data  "package"  are  specified  on  one  or  more  data 
continuation  records  following.  In  these  records,  column  1  must  be  blank,  but 
columns  2-72  may  be  used  freely  for  the  data  and  its  delimiters. 

Each  such  continuation  record  carries  a  "piece"  of  the  data;  these  "pieces" 
will  be  concatenated  in  the  same  order  as  the  continuation  records  to  form  the 
event's  data  package.  On  each  record,  the  data  "piece"  must  be  delimited  on  both 
sides.  On  the  first  continuation  record,  the  left  delimiter  must  be  either  an 
apostrophe  (')  or  a  quote  (");  this  delimiter  must  bo  matched  by  the  right  delimiter 
on  the  last  continuation  record.  All  other  delimiters  (on  multirecord  "packages") 
must  be  ampersands  (&). 

Each  "piece"  may  be  from  1  to  69  characters  long  (excluding  delimiters); 
except  for  the  "piece"  and  its  delimiters,  all  characters  in  the  record  (in  columns 
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1-72)  must  be  blank.  In  other  words,  the  first  and  last  non-blank  characters  of  the 
record  must  be  the  delimiters. 

Within  each  piece,  the  start/end  delimiter  (apostrophe  or  quote)  can  be  itself 
represented  by  doubling  it  in  the  usual  fashion.  No  special  methods  are  used  for 
representing  ampersands;  its  delimiting  function  is  implied  by  its  use  as  the  first  or 
last  non-blank  character  on  a  record.  Let  us  give  a  few  -xamples  to  illustrate  the 
form.  Assume  that  the  "data  package"  is  to  be: 

That's  all,  ladies  &  gentlemen! 

To  represent  it  in  a  single  record,  we  could  use  (assuming  a  starting  column  other 
than  1): 

'That"s  all,  ladies  &  gentlemen!' 
or  alternatively: 

"That's  all,  ladies  &  gentlemen!" 

For  a  multirecord  representation,  we  could  use: 

'That& 

&"s  all,  ladies  && 

&  gentlemen!' 

or  using  a  "staggered"  representation: 

"That's  all& 

&,  ladies  &  gentlemen!" 

4. 2. 7. 2.4. 2  Non-ASCII  (over/under)  Data  Continuation 

In  order  to  represent  octets  which  do  not  correspond  to  printable  ASCII 
codes  (or  to  represent  any  octet,  for  that  matter),  an  "over/under"  technique  is 
used  in  which  two  succeeding  records  represent  a  single  data  "piece",  "special" 
octets  being  represented  two  hexadecimal  digits  in  corresponding  columns  of  the 
two  records,  and  "ordinary"  (ASCII)  octets  being  similarly  represented  by  a  pair  in 
which  one  of  the  records  has  a  blank  in  the  column  concerned. 

A  special  continuation  character  -  the  vertical  bar  (|)  -  is  used  to  delimit  the 
first  of  the  over/under  pair  and  to  indicate  that  such  a  pair  is  beginning.  The 
second  (the  "under"  part)  of  the  pair  is  delimited  exactly  as  are  "single"  records 
(4. 2. 7. 2. 4.1  above),  but  the  delimiters  must  "line  up"  with  the  "|"  delimiters  of 
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the  first  of  the  pair;  i.e.,  they  must  be  in  the  same  columns.  In  both  records  of  the 
pair,  as  in  single  records,  the  delimiters  must  be  the  first  and  last  non-blank 
characters  in  their  records. 

"Special”  octets  are  represented  by  two  hexadecimal  digits  in  corresponding 
columns  of  the  two  records,  with  the  upper  "nibble"  in  the  first  (over)  record,  and 
the  lower  in  the  second.  Also,  because  of  the  "lineup"  requirement,  the 
"horizontal"  doubling,  used  in  the  single-record  form  to  represent  an  instance  of 
the  start/end  delimiter  in  the  data  itself,  can  not  be  used;  instead,  "vertical" 
doubling  (in  which  the  character  occupies  the  same  column  in  both  records  of  the 
pair)  is  employed.  In  all  other  cases,  one  of  the  pair  of  corresponding  columns  in 
the  two  records  must  carry  the  character  to  be  represented,  and  the  other  must  be 
blank. 


To  illustrate  the  method,  let  us  assume  that  the  string  used  in  the  ASCII 
examples  above  must  be  preceded  by  two  octets:  a  parameter  code  (101 10100  in 
binary,  or  "B4"  in  hex)  plus  a  length  indicator  covering  the  string  itself.  This  could 
be  split  into  two  "pieces",  a  "pair"  and  a  "single",  as  follows: 

jbl  '  2  2  | 

'4fThat's0allc  & 

&ladies  &  gentlemen!' 

in  which  the  comma  and  one  of  the  blanks  in  the  first  "piece"  has  been  "hexed". 
Note  the  vertical  doubling  of  the  apostrophe,  which  was  the  start/end  delimiter 
used  in  this  example. 

4. 2. 7. 2.4. 3  Operator  ASCII  Data  Input 

This  method  of  providing  data  for  a  /QUEUE-built  event  is  interactive;  the 
operator  will  be  prompted  for  each  "piece",  and  if  that  piece  does  not  conform  to 
the  expected  format,  the  software  will  immediately  diagnose  the  violation  and 
request  reentry.  The  form  itself  has  been  adapted  for  operator  convenience,  but  is 
essentially  equivalent  to  continuation  format. 

First,  with  certain  exceptions,  "piece"  delimiters  are  optional.  The  data  in 
each  line  entered  are  assumed  to  start  in  column  1 ,  and  end  with  the  last 
non-blank  character  on  the  line.  However,  if  the  character  in  column  1,  or  the  last 
non-blank  character  on  the  line,  is  a  quote  ("),  apostrophe  ('),  ampersand  (&),  or 
vertical  bar  (j),  it  is  assumed  to  be  a  delimiter  and  is  excluded  from  the  data  itself. 

If  column  1 ,  or  the  last  non-blank  character,  of  a  line  is  other  than  one  of  the 
delimiters  above,  "implied"  delimiters  are  assumed.  This  is  as  follows: 
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(1)  On  the  first  line  entered,  the  left  (start)  delimiter  implied  is: 

(a)  a  quote  (")  if  the  last  non-blank  on  the  line  is  a  quote; 

(b)  an  apostrophe  (')  otherwise; 

(2)  An  ampersand  (&)  is  implied  in  all  other  cases. 

In  other  words,  a  "start"  delimiter  is  supplied  for  the  first  "piece",  and 
"continuation"  delimite  s  thereafter.  The  operator  must  therefore  explicitly 
terminate  the  data  witf  a  right  delimiter  on  the  last  piece  which  matches  the 
"start"  delimiter  (explicit  or  implied)  on  the  first  piece.  Except  for  the  required 
column  1  start  and  the  implied  delimiters,  all  the  ASCII  continuation  rules  are  in 
effect.  Let  us  use  the  example  for  ASCII  data  continuation  as  it  might  be  entered 
by  an  operator  (lines  are  assumed  to  start  at  column  1): 

That"s 

all,  ladies  &  & 

gentlemen!' 

Several  points  should  be  noted  in  this  example.  First,  the  implied  apostrophe,  as 
start/end  delimiter,  requires  its  doubling  on  the  first  line  and  its  use  to  terminate 
the  data  on  the  last  line.  Also,  the  explicit  ampersand  (&)  continuation  on  the 
second  line  is  needed  to  "protect"  the  text  ampersand,  which  would  otherwise  be 
interpreted  as  the  delimiter.  Lastly,  note  the  indent  on  the  second  line  which 
represents  a  blank  in  the  data  itself. 

4. 2. 7. 2. 4. 4  Operator  non-ASCII  (over/under)  Data  Input 

As  opposed  to  operator  input  of  plain  ASCII  data,  this  form  requires  explicit 
delimiters  to  satisfy  the  "lineup"  requirements  for  a  pair,  and  the  necessity  to  mark 
the  "over"  record  of  a  pair  as  such  with  the  vertical  bar  (|)  delimiters.  This  causes 
the  form  for  operator  input  of  "over/under"  pairs  to  be  the  same  as  for  continuation 
records,  except  that  "left"  delimiters  must  be  in  column  1 .  To  illustrate  this,  here 
is  the  example  for  "non-ASCII"  continuation  above  as  it  might  be  entered  by  an 
operator  (all  lines  assumed  to  start  in  column  1): 

| bl  '2  2  | 

'4fThat's0allc  & 
ladies  and  gentlemen!' 

Note  that,  as  in  the  data  continuation  example,  "singles"  and  "pairs"  can  be 
mixed,  as  above,  to  provide  the  data  for  a  single  /QUEUE-built  event. 

4. 2. 7. 3  Provision  of  Information  to  Operator 

The  "/NOTE"  command  causes  instructions  or  other  commentary  to  be 
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printed  out  for  the  operator's  edification,  and  may  optionally  serve  as  a 
"breakpoint*  in  the  performance  of  the  test.  The  form  of  the  "/NOTE"  header  is: 

columns  1-8:  /NOTE 
columns  9-16:  pauspec 

The  effect  of  processing  the  /NOTE  command  is  to  echo  following  records,  up  to 
(but  not  including)  the  next  record  that  has  a  slash  (/)  or  dollar  sign  ($)  in  column  1 
(the  /NOTE  header  itself  will  have  been  output  by  the  normal  echoing  of  command 
headers).  Following  this  printout  (or  screen  dispiay),  the  action  taken  depends  on 
the  "pauspec"  parameter  in  columns  9-16. 

The  form  of  the  "pauspec"  parameter  is  either  of: 

PAUSE 

NOPAUSE 

The  first  form  (PAUSE)  results  in  suspension  of  processing,  after  the  operator  has 
been  prompted  to  "HIT  RETURN  TO  PROCEED".  If  the  operator  simply  enters  a 
carriage  return,  processing  of  the  test  script  will  be  resumed.  Entry  of  a  dollar  sign 
in  column  1 ,  however,  will  cause  control  to  be  returned  to  the  event  queue  (like 
the  PROCESS  parameter  in  a  /QUEUE  event;  see  4. 2. 7. 2.1  above).  If,  in  addition, 
the  dollar  sign  is  accompanied  by  a  "T"  or  "Q"  in  column  2,  it  has  the  effect  of  a 
"test  quit"  or  "session  quit"  command  respectively. 

The  othe.  form  (NOPAUSE)  causes  test  processing  to  continue  without 
operator  intervention.  This  is  the  default;  blanks  in  columns  9-16  (or  anything 
other  than  "PAUSE")  has  the  same  effect  as  "NOPAUSE". 

4. 2. 7.4  Test  Script  Termination 

The  test  "script"  is  terminated  explicitly  by  the  "/END"  command,  which  has 
the  following  form- 

columns  1-  8:  /END 
columns  9-16:  prtspec 
columns  17-24:  prgspec 

The  effect  of  the  /END  command  is  to  cause  the  test  processing  to  "turn 
itself  off";  i.e.,  the  user-application  layer  interface  module  thereafter  deletes  the 
poll  event  which  stimulates  it  to  invoke  the  test  processor,  or  otherwise  sets  itself 
to  "ignore"  it.  Event  queue  processing,  however,  continues  to  its  normal  (or 
abnormal)  conclusion.  The  two  parameters  "prtspec"  and  "prgspec"  control 
handling  of  the  test  log  following  completion  of  test  performance.  The  first, 
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"prtspec",  has  one  of  the  following  forms: 

PRINT 
< FORCED > 

NOPRINT 

The  first  and  second  ("<  FORCED  >"  is  generated  by  implied  /END  commands;  see 
below)  forms  cause  the  entire  contents  of  the  log  to  be  printed;  the  third  form 
suppresses  the  printing.  The  default  is  NOPRINT.  The  "prgspec"  parameter  may 
be  either  of: 

PURGE 

NOPURGE 

The  first  form,  "PURGE",  causes  the  log  to  be  purged,  following  its  printing,  if 
indicated;  NOPURGE  causes  the  log  to  remain  "on  file".  NOPURGE  is  the  default. 

If  a  record  with  a  dollar  sign  in  column  1  is  read  from  the  test  processing 
file,  or  end  of  file  is  encountered,  an  /END  record  of  the  following  form  is 
"implied": 

/END 

< FORCED > 

which  terminates  test  processing  and  causes  the  log  to  be  printed  but  not  purged. 

5.0  REVIEW  OF  CURRENT  GROUP  4  FACSIMILE  CCITT  ACTIVITY 

Since  the  completion  of  the  modifications  required  to  align  the  Group  4 
Validation  System  software  with  the  "Blue  Book"  Recommendations,  additional 
work  has  been  done  within  CCITT  Study  Group  VIII  pertaining  to  Group  4 
Facsimile.  Within  the  User/Application  Interface,  this  work  includes  the  refinement 
of  the  T.50G  Recommendations  applicable  to  Group  4  Facsimile  and  the  continued 
definition  of  the  T.430  Recommendations  outlining  the  Document  Transfer  and 
Manipulation  services  and  protocols.  Since  their  release,  the  T.500  Series 
Recommendations  have  been  revised  and  now  further  define  both  the  content  and 
the  architecture  of  the  Group  4  Facsimile  Profiles,  specifically  the  T.503,  T.521, 
and  T.563  Recommendations  defining  the  DTAM  Application  Profile  (Study  Group 
VIII  Contribution  D128,  September,  1990).  In  addition,  the  T.410 
Recommendations  defining  the  Open  Document  Architecture  are  being  expanded  to 
include  provisions  for  document  "tiling",  gray  scale  facsimile  transmission  and 
color  facsimile  transmission  (in  particular,  T.417  Raster  Graphics  Content 
Architecture).  Since  their  release  in  the  "Blue  Books",  updates  have  been  made  to 
the  T.410  series  to  keep  them  in  alignment  with  ISO  8613. 
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Within  the  Application  Layer,  Study  Group  VIII  has  released  Draft 
Recommendation  T.430  which  states  that  the  Association  Control  Services  of  the 
Application  Layer  and  the  Services  of  the  Presentation  Layer  will  be  transparently 
passed  through  when  operating  in  the  "transparent"  mode.  Currently  the  Group  4 
Software  maps  the  DTAM  Services  directly  onto  the  Session  Layer  as  specified  in 
T.521.  Additionally  Study  Group  VIII  has  released  update  and  additions  to  the 
T.430  Series  of  Recommendations  defining  the  DTAM  Model. 

The  Presentation  Layer  has  also  undergone  some  changes.  Initially  defined 
in  the  T.73  Recommendations,  it  is  now  aligned  with  the  OSI  model,  and  defined 
by  the  X.216  and  X.226  Recommendations.  As  previously  mentioned,  the 
Presentation  Layer  presently  acts  simply  as  a  pass-through  layer  between  the 
Application  Layer  and  the  Session  Layer,  according  to  the  Recommendation 
T.62bis.  Most  of  its  functionality  is  now  incorporated  in  the  Application  Layer. 

The  Group  4  Facsimile  Validation  System  software  is  being  modified 
accordingly  to  facilitate  the  above  revisions  and  additions.  These  modifications  are 
mostly  done  on  the  User/Application  interface  and  the  Application  and  Presentation 
Layers.  It  is  anticipated  that  most  of  the  future  standardization  activity  will  occur 
in  these  areas. 
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